[no subject]

[Alexander Alemayhu]

[no subject]

[Alexander Alemayhu]

[PATCH] android: uapi: trivial comment changes

[Alexander Alemayhu]

o s/interupted/interrupted/g
o s/The the/The/g

Signed-off-by: Alexander Alemayhu 
CC: Greg Kroah-Hartman 
CC: Arve Hjønnevåg 
---
 include/uapi/linux/android/binder.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/uapi/linux/android/binder.h 
b/include/uapi/linux/android/binder.h
index 41420e341e75..b3e84e5d36a0 100644
--- a/include/uapi/linux/android/binder.h
+++ b/include/uapi/linux/android/binder.h
@@ -109,7 +109,7 @@ struct binder_version {
  * NOTE: Two special error codes you should check for when calling
  * in to the driver are:
  *
- * EINTR -- The operation has been interupted.  This should be
+ * EINTR -- The operation has been interrupted.  This should be
  * handled by retrying the ioctl() until a different error code
  * is returned.
  *
@@ -266,7 +266,7 @@ enum binder_driver_return_protocol {
 
BR_FAILED_REPLY = _IO('r', 17),
/*
-* The the last transaction (either a bcTRANSACTION or
+* The last transaction (either a bcTRANSACTION or
 * a bcATTEMPT_ACQUIRE) failed (e.g. out of memory).  No parameters.
 */
 };
-- 
2.11.0

[PATCH 1/2 linux-next] ext4: check inode permissions in ext4_ioctl()

[Fabian Frederick]

According to other FS like UDF, ioctl has to check if inode
is readable before proceeding otherwise permissions updated between
file opening and ioctl are ignored.

Set operations were already protected but nothing around
get like EXT4_IOC_GETVERSION

This patch applies the same test than udf_ioctl() but returns
-EACCES "permission denied" like the rest of ext4_ioctl()

Signed-off-by: Fabian Frederick 
---
 fs/ext4/ioctl.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
index 49fd137..4f113e6 100644
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@ -449,6 +449,9 @@ long ext4_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
struct ext4_inode_info *ei = EXT4_I(inode);
unsigned int flags;
 
+   if (inode_permission(inode, MAY_READ) != 0)
+   return -EACCES;
+
ext4_debug("cmd = %u, arg = %lu\n", cmd, arg);
 
switch (cmd) {
-- 
2.7.4

[PATCH 2/2 linux-next] ext4: return -EACCES on inode_owner_or_capable() error

[Fabian Frederick]

like other cases in ext4_ioctl()

Signed-off-by: Fabian Frederick 
---
 fs/ext4/ioctl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
index 4f113e6..5654ccd 100644
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@ -501,7 +501,7 @@ long ext4_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
int err;
 
if (!inode_owner_or_capable(inode))
-   return -EPERM;
+   return -EACCES;
 
if (ext4_has_metadata_csum(inode->i_sb)) {
ext4_warning(sb, "Setting inode version is not "
-- 
2.7.4

Re: [PATCH v6 7/9] i2c: i2c-mux-simple: new driver

[Jonathan Cameron]

On 30/11/16 08:17, Peter Rosin wrote:
> This is a generic simple i2c mux that uses the generic multiplexer
> subsystem to do the muxing.
> 
> The user can select if the mux is to be mux-locked and parent-locked
> as described in Documentation/i2c/i2c-topology.
> 
> Signed-off-by: Peter Rosin 
Looks good to me though as I haven't really commented on it I'll give
an Ack rather than a reviewed by.

Acked-by: Jonathan Cameron 
> ---
>  drivers/i2c/muxes/Kconfig  |  13 +++
>  drivers/i2c/muxes/Makefile |   1 +
>  drivers/i2c/muxes/i2c-mux-simple.c | 179 
> +
>  3 files changed, 193 insertions(+)
>  create mode 100644 drivers/i2c/muxes/i2c-mux-simple.c
> 
> diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
> index 10b3d17ae3ea..565921e09a96 100644
> --- a/drivers/i2c/muxes/Kconfig
> +++ b/drivers/i2c/muxes/Kconfig
> @@ -73,6 +73,19 @@ config I2C_MUX_REG
> This driver can also be built as a module.  If so, the module
> will be called i2c-mux-reg.
>  
> +config I2C_MUX_SIMPLE
> + tristate "Simple I2C multiplexer"
> + select MULTIPLEXER
> + depends on OF
> + help
> +   If you say yes to this option, support will be included for a
> +   simple generic I2C multiplexer. This driver provides access to
> +   I2C busses connected through a MUX, which is controlled
> +   by a generic MUX controller.
> +
> +   This driver can also be built as a module.  If so, the module
> +   will be called i2c-mux-simple.
> +
>  config I2C_DEMUX_PINCTRL
>   tristate "pinctrl-based I2C demultiplexer"
>   depends on PINCTRL && OF
> diff --git a/drivers/i2c/muxes/Makefile b/drivers/i2c/muxes/Makefile
> index 9948fa45037f..6821d95c92a3 100644
> --- a/drivers/i2c/muxes/Makefile
> +++ b/drivers/i2c/muxes/Makefile
> @@ -11,5 +11,6 @@ obj-$(CONFIG_I2C_MUX_PCA9541)   += i2c-mux-pca9541.o
>  obj-$(CONFIG_I2C_MUX_PCA954x)+= i2c-mux-pca954x.o
>  obj-$(CONFIG_I2C_MUX_PINCTRL)+= i2c-mux-pinctrl.o
>  obj-$(CONFIG_I2C_MUX_REG)+= i2c-mux-reg.o
> +obj-$(CONFIG_I2C_MUX_SIMPLE) += i2c-mux-simple.o
>  
>  ccflags-$(CONFIG_I2C_DEBUG_BUS) := -DDEBUG
> diff --git a/drivers/i2c/muxes/i2c-mux-simple.c 
> b/drivers/i2c/muxes/i2c-mux-simple.c
> new file mode 100644
> index ..4a03493e1ad7
> --- /dev/null
> +++ b/drivers/i2c/muxes/i2c-mux-simple.c
> @@ -0,0 +1,179 @@
> +/*
> + * Generic simple I2C multiplexer
> + *
> + * Copyright (C) 2016 Axentia Technologies AB
> + *
> + * Author: Peter Rosin 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct mux {
> + struct mux_control *control;
> +
> + bool do_not_deselect;
> +};
> +
> +static int i2c_mux_select(struct i2c_mux_core *muxc, u32 chan)
> +{
> + struct mux *mux = i2c_mux_priv(muxc);
> + int ret;
> +
> + ret = mux_control_select(mux->control, chan);
> + mux->do_not_deselect = ret < 0;
> +
> + return ret;
> +}
> +
> +static int i2c_mux_deselect(struct i2c_mux_core *muxc, u32 chan)
> +{
> + struct mux *mux = i2c_mux_priv(muxc);
> +
> + if (mux->do_not_deselect)
> + return 0;
> +
> + return mux_control_deselect(mux->control);
> +}
> +
> +static struct i2c_adapter *mux_parent_adapter(struct device *dev)
> +{
> + struct device_node *np = dev->of_node;
> + struct device_node *parent_np;
> + struct i2c_adapter *parent;
> +
> + parent_np = of_parse_phandle(np, "i2c-parent", 0);
> + if (!parent_np) {
> + dev_err(dev, "Cannot parse i2c-parent\n");
> + return ERR_PTR(-ENODEV);
> + }
> + parent = of_find_i2c_adapter_by_node(parent_np);
> + of_node_put(parent_np);
> + if (!parent)
> + return ERR_PTR(-EPROBE_DEFER);
> +
> + return parent;
> +}
> +
> +static const struct of_device_id i2c_mux_of_match[] = {
> + { .compatible = "i2c-mux-simple,parent-locked",
> +   .data = (void *)0, },
> + { .compatible = "i2c-mux-simple,mux-locked",
> +   .data = (void *)1, },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, i2c_mux_of_match);
> +
> +static int i2c_mux_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *np = dev->of_node;
> + struct device_node *child;
> + const struct of_device_id *match;
> + struct i2c_mux_core *muxc;
> + struct mux *mux;
> + struct i2c_adapter *parent;
> + int children;
> + int ret;
> +
> + if (!np)
> + return -ENODEV;
> +
> + mux = devm_kzalloc(dev, sizeof(*mux), GFP_KERNEL);
> + if (!mux)
> + return -ENOMEM;
> +
> + mux->control = devm_mux_control_get(dev, NULL);
> + if (IS_ERR(mux->control)) {
> + if (PTR_ERR(mux->con

[PATCH v2] drivers: remoteproc: constify rproc_ops structures

[Bhumika Goyal]

Declare rproc_ops structures as const as they are only passed as an
argument to the function rproc_alloc. This argument is of type const, so
rproc_ops structures having this property can be declared const too.
Done using Coccinelle:

@r1 disable optional_qualifier @
identifier i;
position p;
@@
static struct rproc_ops i@p = {...};

@ok1@
identifier r1.i;
position p;
@@
rproc_alloc(...,&i@p,...)

@bad@
position p!={r1.p,ok1.p};
identifier r1.i;
@@
i@p

@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
+const
struct rproc_ops i;

File size details:

Size of the file remoteproc/da8xx_remoteproc.o remains the same before and
after applying the changes.

   textdata bss dec hex filename
   1312 100   41416 588 remoteproc/da8xx_remoteproc.o
   1312 100   41416 588 remoteproc/da8xx_remoteproc.o

970 240   01210 4ba remoteproc/omap_remoteproc.o
   1002 192   01194 4aa remoteproc/omap_remoteproc.o

   1901 240   02141 85d remoteproc/st_remoteproc.o
   1933 192   02125 84d remoteproc/st_remoteproc.o

   1288  96   01384 568 remoteproc/st_slim_rproc.o
   1320  64   01384 568 remoteproc/st_slim_rproc.o

   2121 240   02361 939 remoteproc/wkup_m3_rproc.o
   2161 192   02353 931 remoteproc/wkup_m3_rproc.o

Signed-off-by: Bhumika Goyal 
---
Changes in v2:
 * Apply the changes to the file da8xx_remoteproc.c as well.

 drivers/remoteproc/da8xx_remoteproc.c | 2 +-
 drivers/remoteproc/omap_remoteproc.c  | 2 +-
 drivers/remoteproc/st_remoteproc.c| 2 +-
 drivers/remoteproc/st_slim_rproc.c| 2 +-
 drivers/remoteproc/wkup_m3_rproc.c| 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/remoteproc/da8xx_remoteproc.c 
b/drivers/remoteproc/da8xx_remoteproc.c
index 1afac8f..3814de2 100644
--- a/drivers/remoteproc/da8xx_remoteproc.c
+++ b/drivers/remoteproc/da8xx_remoteproc.c
@@ -151,7 +151,7 @@ static void da8xx_rproc_kick(struct rproc *rproc, int vqid)
writel(SYSCFG_CHIPSIG2, drproc->chipsig);
 }
 
-static struct rproc_ops da8xx_rproc_ops = {
+static const struct rproc_ops da8xx_rproc_ops = {
.start = da8xx_rproc_start,
.stop = da8xx_rproc_stop,
.kick = da8xx_rproc_kick,
diff --git a/drivers/remoteproc/omap_remoteproc.c 
b/drivers/remoteproc/omap_remoteproc.c
index fa63bf2..a96ce90 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -177,7 +177,7 @@ static int omap_rproc_stop(struct rproc *rproc)
return 0;
 }
 
-static struct rproc_ops omap_rproc_ops = {
+static const struct rproc_ops omap_rproc_ops = {
.start  = omap_rproc_start,
.stop   = omap_rproc_stop,
.kick   = omap_rproc_kick,
diff --git a/drivers/remoteproc/st_remoteproc.c 
b/drivers/remoteproc/st_remoteproc.c
index da4e152..f21787b 100644
--- a/drivers/remoteproc/st_remoteproc.c
+++ b/drivers/remoteproc/st_remoteproc.c
@@ -107,7 +107,7 @@ static int st_rproc_stop(struct rproc *rproc)
return sw_err ?: pwr_err;
 }
 
-static struct rproc_ops st_rproc_ops = {
+static const struct rproc_ops st_rproc_ops = {
.start  = st_rproc_start,
.stop   = st_rproc_stop,
 };
diff --git a/drivers/remoteproc/st_slim_rproc.c 
b/drivers/remoteproc/st_slim_rproc.c
index 507716c..6cfd862 100644
--- a/drivers/remoteproc/st_slim_rproc.c
+++ b/drivers/remoteproc/st_slim_rproc.c
@@ -200,7 +200,7 @@ static void *slim_rproc_da_to_va(struct rproc *rproc, u64 
da, int len)
return va;
 }
 
-static struct rproc_ops slim_rproc_ops = {
+static const struct rproc_ops slim_rproc_ops = {
.start  = slim_rproc_start,
.stop   = slim_rproc_stop,
.da_to_va   = slim_rproc_da_to_va,
diff --git a/drivers/remoteproc/wkup_m3_rproc.c 
b/drivers/remoteproc/wkup_m3_rproc.c
index 18175d0..1ada0e5 100644
--- a/drivers/remoteproc/wkup_m3_rproc.c
+++ b/drivers/remoteproc/wkup_m3_rproc.c
@@ -111,7 +111,7 @@ static void *wkup_m3_rproc_da_to_va(struct rproc *rproc, 
u64 da, int len)
return va;
 }
 
-static struct rproc_ops wkup_m3_rproc_ops = {
+static const struct rproc_ops wkup_m3_rproc_ops = {
.start  = wkup_m3_rproc_start,
.stop   = wkup_m3_rproc_stop,
.da_to_va   = wkup_m3_rproc_da_to_va,
-- 
1.9.1

Re: [PATCH v6 8/9] dt-bindings: mux-adg792a: document devicetree bindings for ADG792A/G mux

[Jonathan Cameron]

On 30/11/16 08:17, Peter Rosin wrote:
> Analog Devices ADG792A/G is a triple 4:1 mux.
> 
> Signed-off-by: Peter Rosin 
Few comments inline.  Worth adding anything about the gpio (output pins) to
the binding at this stage as well?  Would certainly be nice to support
them.

Jonathan
> ---
>  .../devicetree/bindings/misc/mux-adg792a.txt   | 64 
> ++
>  1 file changed, 64 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/misc/mux-adg792a.txt
> 
> diff --git a/Documentation/devicetree/bindings/misc/mux-adg792a.txt 
> b/Documentation/devicetree/bindings/misc/mux-adg792a.txt
> new file mode 100644
> index ..4677f9ab1c55
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/mux-adg792a.txt
> @@ -0,0 +1,64 @@
> +Bindings for Analog Devices ADG792A/G Triple 4:1 Multiplexers
> +
> +Required properties:
> +- compatible : "adi,adg792a" or "adi,adg792g"
> +- #mux-control-cells : <0> if parallel, or <1> if not.
> +* Standard mux-controller bindings as decribed in mux-controller.txt
> +
> +Optional properties:
> +- adi,parallel : if present, the three muxes are bound together with a single
> +  mux controller, controlling all three muxes in parallel.
> +- adi,idle-state : if present, array of states the three mux controllers will
> +  have when idle (or, if parallel, a single idle-state).
Hmm. These are actually a policy decision.  As only one policy will make
sense for a given set of hardware probably fine to have it in here I guess.
Might be worth adding a note to say this though.
> +
> +Mux controller states 0 through 3 correspond to signals A through D in the
> +datasheet. Mux controller states 4 and 5 are only available as possible idle
> +states. State 4 represents that nothing is connected, and state 5 represents
> +that the mux controller keeps the mux in its previously selected state during
> +the idle period. State 5 is the default idle state.
I'm never a great fan of magic numbers.  Can we represent this more cleanly by
breaking it into multiple properties?
Optional:
adi,idle-switch-to-channel : switch to this channel when idle.
adi,idle-high-impedance :  the nothing connected state?

If neither present leaves it in previous state?
> +
> +Example:
> +
> + /* three independent mux controllers (of which one is used) */
> + &i2c0 {
> + mux: adg792a@50 {
> + compatible = "adi,adg792a";
> + reg = <0x50>;
> + #mux-control-cells = <1>;
> + };
> + };
> +
> + adc-mux {
> + compatible = "iio-mux";
> + io-channels = <&adc 0>;
> + io-channel-names = "parent";
> +
> + mux-controls = <&mux 1>;
> +
> + channels = "sync-1", "", "out";
> + };
> +
> +
> + /*
> +  * Three parallel muxes with one mux controller, useful e.g. if
> +  * the adc is differential, thus needing two signals to be muxed
> +  * simultaneously for correct operation.
> +  */
> + &i2c0 {
> + pmux: adg792a@50 {
> + compatible = "adi,adg792a";
> + reg = <0x50>;
> + #mux-control-cells = <0>;
> + adi,parallel;
> + };
> + };
> +
> + diff-adc-mux {
> + compatible = "iio-mux";
> + io-channels = <&adc 0>;
> + io-channel-names = "parent";
> +
> + mux-controls = <&pmux>;
> +
> + channels = "sync-1", "", "out";
> + };
> 

[PATCH V2 1/2 linux-next] ext4: check inode permissions in ext4_ioctl()

[Fabian Frederick]

According to other FS like UDF, ioctl has to check if inode
is readable before proceeding otherwise permissions updated between
file opening and ioctl are ignored.

Set operations were already protected but nothing around
get like EXT4_IOC_GETVERSION

This patch applies the same test than udf_ioctl() but returns
-EACCES "permission denied" like the rest of ext4_ioctl()

Signed-off-by: Fabian Frederick 
---
V2: check readability in get operations only.

 fs/ext4/ioctl.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
index 49fd137..f665c02 100644
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@ -453,6 +453,9 @@ long ext4_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
 
switch (cmd) {
case EXT4_IOC_GETFLAGS:
+   if (inode_permission(inode, MAY_READ) != 0)
+   return -EACCES;
+
ext4_get_inode_flags(ei);
flags = ei->i_flags & EXT4_FL_USER_VISIBLE;
return put_user(flags, (int __user *) arg);
@@ -489,6 +492,9 @@ long ext4_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
}
case EXT4_IOC_GETVERSION:
case EXT4_IOC_GETVERSION_OLD:
+   if (inode_permission(inode, MAY_READ) != 0)
+   return -EACCES;
+
return put_user(inode->i_generation, (int __user *) arg);
case EXT4_IOC_SETVERSION:
case EXT4_IOC_SETVERSION_OLD: {
@@ -834,12 +840,18 @@ long ext4_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
 #endif
}
case EXT4_IOC_GET_ENCRYPTION_POLICY:
+   if (inode_permission(inode, MAY_READ) != 0)
+   return -EACCES;
+
return fscrypt_ioctl_get_policy(filp, (void __user *)arg);
 
case EXT4_IOC_FSGETXATTR:
{
struct fsxattr fa;
 
+   if (inode_permission(inode, MAY_READ) != 0)
+   return -EACCES;
+
memset(&fa, 0, sizeof(struct fsxattr));
ext4_get_inode_flags(ei);
fa.fsx_xflags = ext4_iflags_to_xflags(ei->i_flags & 
EXT4_FL_USER_VISIBLE);
-- 
2.7.4

[PATCH V2 2/2 linux-next] ext4: return -EACCES on inode_owner_or_capable() error

[Fabian Frederick]

like other cases in ext4_ioctl()

Signed-off-by: Fabian Frederick 
---
 fs/ext4/ioctl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
index f665c02..3926657 100644
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@ -504,7 +504,7 @@ long ext4_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
int err;
 
if (!inode_owner_or_capable(inode))
-   return -EPERM;
+   return -EACCES;
 
if (ext4_has_metadata_csum(inode->i_sb)) {
ext4_warning(sb, "Setting inode version is not "
-- 
2.7.4

Re: Stopping watchdog in watchdog driver remove functions

[Wim Van Sebroeck]

Hi Guenter,

> I noticed that several watchdog drivers stop the watchdog in trhe driver 
> remove function.
> A non-exhaustive list of drivers doing that is
> 
>   drivers/watchdog/bcm7038_wdt.c
>   drivers/watchdog/cadence_wdt.c
>   drivers/watchdog/imgpdc_wdt.c
>   drivers/watchdog/jz4740_wdt.c
>   drivers/watchdog/kempld_wdt.c
>   drivers/watchdog/max77620_wdt.c
>   drivers/watchdog/moxart_wdt.c
>   drivers/watchdog/sama5d4_wdt.c
>   drivers/watchdog/tangox_wdt.c
>   drivers/watchdog/tegra_wdt.c
> 
> Since a watchdog has to be closed for its driver to be removable, one 
> situation
> where a watchdog is still running on unload is where the watchdog was 
> opened but
> not closed properly (eg by killing the watchdog application, or if the 
> 'nowayout'
> flag is set).
> 
> Given that, does it even make sense to stop the watchdog in the remove 
> function ?
> Should it even be permitted ?

>From an API point of view: if WDIOF_MAGICCLOSE is being used then the watchdog
_SHOULD_ continue to run when the watchdog was not properly closed (which
normally also results in a reboot of the system).
if WDIOF_MAGICCLOSE is not being used then closing the watchdog device means
that the driver needs to stop the watchdog.

Kind regards and happy new year to you all,
Wim.

Re: [PATCH v6 9/9] misc: mux-adg792a: add mux controller driver for ADG792A/G

[Jonathan Cameron]

On 30/11/16 08:17, Peter Rosin wrote:
> Analog Devices ADG792A/G is a triple 4:1 mux.
> 
> Signed-off-by: Peter Rosin 
Looks pretty good. Some minor suggestions inline.

This convinced me of two things:
1. Need a separate subsystem directory for muxes - having them under misc
is going to lead to long term mess.
2. Devm alloc and registration functions will make the drivers all simpler.

Also, browsing through ADIs list of muxes and switches it's clear that
one classic case will be where an i2c octal or similar switch is used with
outputs wired together in weird combinations to act as a mux.  Going to
be 'fun' describing that.

There are also potentially cross point switches to be described ;)
(I had to look up what one of those was ;)

Crosspoints aren't implausible as front ends for ADCs as you might
want to be able rapidly sample any 2 of say 16 channels coming from
for example a max14661.  We'd have to figure out how to add buffered
capture support with sensible restrictions to the iio-mux driver
to do that - realistically I think we would just not allow buffered
capture with the mux having to switch.  Without hardware support
(i.e. an ADC with external mux control) it would be too slow.

Always good to bury some idle thoughts deep in the review of a random
driver ;) I'll never be able to remember where they were let alone
anyone else.

Jonathan

> ---
>  drivers/misc/Kconfig   |  12 
>  drivers/misc/Makefile  |   1 +
>  drivers/misc/mux-adg792a.c | 154 
> +
>  3 files changed, 167 insertions(+)
>  create mode 100644 drivers/misc/mux-adg792a.c
> 
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 2ce675e410c5..45567a444bbf 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -780,6 +780,18 @@ menuconfig MULTIPLEXER
>  
>  if MULTIPLEXER
>  
> +config MUX_ADG792A
> + tristate "Analog Devices ADG792A/ADG792G Multiplexers"
> + depends on I2C
> + help
> +   ADG792A and ADG792G Wide Bandwidth Triple 4:1 Multiplexers
> +
> +   The driver supports both operating the three multiplexers in
> +   parellel and operating them independently.
parallel
> +
> +   To compile the driver as a module, choose M here: the module will
> +   be called mux-adg792a.
> +
>  config MUX_GPIO
>   tristate "GPIO-controlled Multiplexer"
>   depends on OF && GPIOLIB
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index 0befa2bba762..10ab8d34c9e5 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -54,6 +54,7 @@ obj-$(CONFIG_VEXPRESS_SYSCFG)   += vexpress-syscfg.o
>  obj-$(CONFIG_CXL_BASE)   += cxl/
>  obj-$(CONFIG_PANEL) += panel.o
>  obj-$(CONFIG_MULTIPLEXER)+= mux-core.o
> +obj-$(CONFIG_MUX_ADG792A)+= mux-adg792a.o
>  obj-$(CONFIG_MUX_GPIO)   += mux-gpio.o
>  
>  lkdtm-$(CONFIG_LKDTM)+= lkdtm_core.o
> diff --git a/drivers/misc/mux-adg792a.c b/drivers/misc/mux-adg792a.c
> new file mode 100644
> index ..7d309a78af65
> --- /dev/null
> +++ b/drivers/misc/mux-adg792a.c
> @@ -0,0 +1,154 @@
> +/*
> + * Multiplexer driver for Analog Devices ADG792A/G Triple 4:1 mux
> + *
> + * Copyright (C) 2016 Axentia Technologies AB
> + *
> + * Author: Peter Rosin 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define ADG792A_LDSW BIT(0)
> +#define ADG792A_RESETBIT(1)
> +#define ADG792A_DISABLE(mux) (0x50 | (mux))
> +#define ADG792A_DISABLE_ALL  (0x5f)
> +#define ADG792A_MUX(mux, state)  (0xc0 | (((mux) + 1) << 2) | (state))
> +#define ADG792A_MUX_ALL(state)   (0xc0 | (state))
> +
> +#define ADG792A_DISABLE_STATE(4)
> +#define ADG792A_KEEP_STATE   (5)
> +
> +static int adg792a_set(struct mux_control *mux, int state)
> +{
> + struct i2c_client *i2c = to_i2c_client(mux->chip->dev.parent);
> + u8 cmd;
> +
> + if (mux->chip->controllers == 1) {
> + /* parallel mux controller operation */
> + if (state == ADG792A_DISABLE_STATE)
> + cmd = ADG792A_DISABLE_ALL;
> + else
> + cmd = ADG792A_MUX_ALL(state);
> + } else {
> + unsigned int controller = mux_control_get_index(mux);
> +
> + if (state == ADG792A_DISABLE_STATE)
> + cmd = ADG792A_DISABLE(controller);
> + else
> + cmd = ADG792A_MUX(controller, state);
> + }
> +
> + return i2c_smbus_write_byte_data(i2c, cmd, ADG792A_LDSW);
> +}
> +
> +static const struct mux_control_ops adg792a_ops = {
> + .set = adg792a_set,
> +};
> +
> +static int adg792a_probe(struct i2c_client *i2c,
> +  const struct i2c_device_id *id)
> +{

Re: [PATCH v6 0/9] mux controller abstraction and iio/i2c muxes

[Jonathan Cameron]

On 30/11/16 08:16, Peter Rosin wrote:
> Hi!
Just a quick note to encourage people to take a look at this series
if they have the time (I can't talk as it took me almost exactly a
month to take a proper look).

It actually ended up a good deal simpler than I expected so I'm falling
on the side of this making sense rather than pushing all mux complexity
into a 'card driver'.  Covers a lot of cases without a proliferation of
code which is nice.

One addition that may make sense is to provide hooks to allow 'card
drivers' where they are needed. I can certainly conceive of devices
where the complexity does rise to the point where they make sense.
However, we can add them when needed.

Peter, don't give up on this set just yet!

Happy New Year,

Jonathan
> 
> v5 -> v6 changes
> - fix stupidity in mux_chip_priv, mux_gpio_remove and adg792a_remove.
> - change the devicetree bindings for the iio-mux to use a list of strings
>   (channels property) instead of a list children.
> 
> v4 -> v5 changes
> - remove support for fancier dt layouts and go back to the phandle
>   approach from v2 and before, killing the horrible non-working
>   refcounting crap from v4 and avoiding a bunch of life-time issues
>   in v3.
> - introduce the concept of a mux-chip, that can hold one or more
>   mux-controllers (inspired by the pwm subsystem).
> - add dt #mux-control-cells property needed to get to the desired
>   mux controller if a mux chip provides more than one.
> - take away the option to build the mux-core as a module.
> - if the mux controller has an idle state, make sure the mux controller
>   is set up in the idle state initially (when it should be idle).
> - do not use a variable length array on the stack in mux_gpio_set to
>   temporarily store the gpio state, preallocate space instead.
> - fix resource leak on one failure path in mux_gpio_probe.
> - driver for Analog Devices ADG792A/G, literally the first mux chip
>   I found on the Internet with an i2c interface (that was not a
>   dedicated i2c multiplexer like PCA9547) which I used to verify
>   that the abstractions in the mux core are up to the task. Untested,
>   just proof of concept that at least looks pretty and compiles...
> - various touch-ups.
> 
> v3 -> v4 changes
> - rebased onto next-20161122 (depends on recent _available iio changes).
> - added support for having the mux-controller in a child node of a
>   mux-consumer if it is a sole consumer, to hopefully even further satisfy
>   the complaint from Rob (and later Lars-Peter) about dt complexity.
> - the above came at the cost of some rather horrible refcounting code,
>   please review and suggest how it should be done...
> - changed to register a device class instead of a bus.
> - pass in the parent device into mux_control_alloc and require less
>   work from mux-control drivers.
> - changed device names from mux:control%d to mux%d
> - move kernel-doc from mux-core.c to mux.h (and add some bits).
> - give the gpio driver a chance to update all mux pins at once.
> - factor out iio ext_info lookup into new helper function. /Lars-Peter
> - use an unsigned type for the iio ext_info count. /Lars-Peter
> - unified "brag strings" in the file headers.
> 
> v2 -> v3 changes
> - have the mux-controller in the parent node of any mux-controller consumer,
>   to hopefully satisfy complaint from Rob about dt complexity.
> - improve commit message of the mux subsystem commit, making it more
>   general, as requested by Jonathan.
> - remove priv member from struct mux_control and calculate it on the
>   fly. /Jonathan
> - make the function comments in mux-core.c kernel doc. /Jonathan
> - add devm_mux_control_* to Documentation/driver.model/devres.txt. /Jonathan
> - add common dt bindings for mux-controllers, refer to them from the
>   mux-gpio bindings. /Rob
> - clarify how the gpio pins map to the mux state. /Rob
> - separate CONFIG_ variables for the mux core and the mux gpio driver.
> - improve Kconfig help texts.
> - make CONFIG_MUX_GPIO depend on CONFIG_GPIOLIB.
> - keep track of the number of mux states in the mux core.
> - since the iio channel number is used as mux state, it was possible
>   to drop the state member from the mux_child struct.
> - cleanup dt bindings for i2c-mux-simple, it had some of copy-paste
>   problems from ots origin (i2c-mux-gpio).
> - select the mux control subsystem in config for the i2c-mux-simple driver.
> - add entries to MAINTAINERS and my sign-off, I'm now satisfied and know
>   nothing in this to be ashamed of.
> 
> v1 -> v2 changes
> - fixup export of mux_control_put reported by kbuild
> - drop devicetree iio-ext-info property as noted by Lars-Peter,
>   and replace the functionality by exposing all ext_info
>   attributes of the parent channel for each of the muxed
>   channels. A cache on top of that and each muxed channel
>   gets its own view of the ext_info of the parent channel.
> - implement idle-state for muxes
> - clear out the cache on failure in order to force a mux
>

Re: [PATCH] scsi: mpt3sas: fix hang on ata passthru commands

[Bart Van Assche]

On Sat, 2016-12-31 at 15:19 -0800, James Bottomley wrote:
> On Thu, 2016-12-29 at 00:02 -0800, Christoph Hellwig wrote:
> > On Wed, Dec 28, 2016 at 11:30:24PM -0500, Jason Baron wrote:
> > > Add a new parameter to scsi_internal_device_block() to decide 
> > > whether or not to invoke scsi_wait_for_queuecommand().
> > 
> > We'll also need to deal with the blk-mq wait path that Bart has been
> > working on (I think it's already in the scsi tree, but I'd have to
> > check).
> > 
> > Also adding a bool flag for the last call in a function is style 
> > that's a little annoying.
> > 
> > I'd prefer to add a scsi_internal_device_block_nowait that contains
> > all the code except for the waiting, and then make
> > scsi_internal_device_block_nowait a wrapper around it.  Or drop the
> > annoying internal for both while we're at it :)
> 
> OK, I know it's new year, but this is an unpatched regression in -rc1
> that's causing serious issues.  I would like this fixed by -rc3 so we
> have 3 options
> 
>1. revert all the queuecommand wait stuff until it proves it's actually
>   working without regressions
>2. apply this patch and fix the style issues later
>3. someone else supplies the correctly styled fix patch
> 
> The conservative in me says that 1. is probably the most correct thing
> to do because it gives us time to get the queuecommand wait stuff
> right; that's what I'll probably do if there's no movement next week. 
>  However, since we're reasonably early in the -rc cycle, so either 2 or
> 3 are viable provided no further regressions caused by the queuecommand
> wait stuff pop up.

Hello James,

My recommendation is to revert commit 18f6084a989b ("scsi: mpt3sas: Fix
secure erase premature termination"). Since the mpt3sas driver uses the
single-queue approach and since the SCSI core unlocks the block layer
request queue lock before the .queuecommand callback function is called,
multiple threads can execute that callback function (scsih_qcmd() in this
case) simultaneously. This means that using scsi_internal_device_block()
from inside .queuecommand to serialize SCSI command execution is wrong.

Bart.

Re: Stopping watchdog in watchdog driver remove functions

[Andy Shevchenko]

On Sun, Jan 1, 2017 at 1:14 PM, Wim Van Sebroeck  wrote:

>> Given that, does it even make sense to stop the watchdog in the remove
>> function ?
>> Should it even be permitted ?
>
> From an API point of view: if WDIOF_MAGICCLOSE is being used then the watchdog
> _SHOULD_ continue to run when the watchdog was not properly closed (which
> normally also results in a reboot of the system).

Btw, some systems may require watchdog to be run in order to perform reboot.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] scsi: mpt3sas: fix hang on ata passthru commands

[Jason Baron]

On 01/01/2017 09:22 AM, Bart Van Assche wrote:
> On Sat, 2016-12-31 at 15:19 -0800, James Bottomley wrote:
>> On Thu, 2016-12-29 at 00:02 -0800, Christoph Hellwig wrote:
>>> On Wed, Dec 28, 2016 at 11:30:24PM -0500, Jason Baron wrote:
 Add a new parameter to scsi_internal_device_block() to decide 
 whether or not to invoke scsi_wait_for_queuecommand().
>>> We'll also need to deal with the blk-mq wait path that Bart has been
>>> working on (I think it's already in the scsi tree, but I'd have to
>>> check).
>>>
>>> Also adding a bool flag for the last call in a function is style 
>>> that's a little annoying.
>>>
>>> I'd prefer to add a scsi_internal_device_block_nowait that contains
>>> all the code except for the waiting, and then make
>>> scsi_internal_device_block_nowait a wrapper around it.  Or drop the
>>> annoying internal for both while we're at it :)
>> OK, I know it's new year, but this is an unpatched regression in -rc1
>> that's causing serious issues.  I would like this fixed by -rc3 so we
>> have 3 options
>>
>>1. revert all the queuecommand wait stuff until it proves it's actually
>>   working without regressions
>>2. apply this patch and fix the style issues later
>>3. someone else supplies the correctly styled fix patch
>>
>> The conservative in me says that 1. is probably the most correct thing
>> to do because it gives us time to get the queuecommand wait stuff
>> right; that's what I'll probably do if there's no movement next week. 
>>  However, since we're reasonably early in the -rc cycle, so either 2 or
>> 3 are viable provided no further regressions caused by the queuecommand
>> wait stuff pop up.
> Hello James,
>
> My recommendation is to revert commit 18f6084a989b ("scsi: mpt3sas: Fix
> secure erase premature termination"). Since the mpt3sas driver uses the
> single-queue approach and since the SCSI core unlocks the block layer
> request queue lock before the .queuecommand callback function is called,
> multiple threads can execute that callback function (scsih_qcmd() in this
> case) simultaneously. This means that using scsi_internal_device_block()
> from inside .queuecommand to serialize SCSI command execution is wrong.
>
> Bart.

Hi,

Yes, commit 18f6084a989b looked racy to me as well. I noted that
in a follow up to my patch, and a suggested a way of fixing it:
http://lkml.iu.edu/hypermail/linux/kernel/1612.3/01301.html

Also worth noting is that commit 18f6084a989b was backported
to at least 4.8 stable.

Thanks,

-Jason

Re: [PATCH v6 7/9] i2c: i2c-mux-simple: new driver

[Andy Shevchenko]

On Wed, Nov 30, 2016 at 10:17 AM, Peter Rosin  wrote:
> This is a generic simple i2c mux that uses the generic multiplexer
> subsystem to do the muxing.

> +static const struct of_device_id i2c_mux_of_match[] = {
> +   { .compatible = "i2c-mux-simple,parent-locked",
> + .data = (void *)0, },
> +   { .compatible = "i2c-mux-simple,mux-locked",
> + .data = (void *)1, },
> +   {},
> +};

Perhaps

#define I2C_MUX_LOCKED_PARENT  0
#define I2C_MUX_LOCKED 1

?

-- 
With Best Regards,
Andy Shevchenko

[PATCH] coccinelle: check that dmi_system_id structures are null terminated

[Julia Lawall]

Add dmi_system_id to the list of types for which top-level arrays are
checked to be null terminated.

Signed-off-by: Julia Lawall 

---
 scripts/coccinelle/misc/of_table.cocci |   21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/scripts/coccinelle/misc/of_table.cocci 
b/scripts/coccinelle/misc/of_table.cocci
index 2294915..d1b666f 100644
--- a/scripts/coccinelle/misc/of_table.cocci
+++ b/scripts/coccinelle/misc/of_table.cocci
@@ -1,4 +1,5 @@
-/// Make sure (of/i2c/platform)_device_id tables are NULL terminated
+/// Make sure (of/i2c/platform)_device_id and dmi_system_id tables are
+/// NULL terminated
 //
 // Keywords: of_table i2c_table platform_table
 // Confidence: Medium
@@ -14,14 +15,16 @@ identifier var, arr;
 expression E;
 @@
 (
-struct \(of_device_id \| i2c_device_id \| platform_device_id\) arr[] = {
+struct
+  \(of_device_id\|i2c_device_id\|platform_device_id\|dmi_system_id\) arr[] = {
...,
{
.var = E,
 *  }
 };
 |
-struct \(of_device_id \| i2c_device_id \| platform_device_id\) arr[] = {
+struct
+  \(of_device_id\|i2c_device_id\|platform_device_id\|dmi_system_id\) arr[] = {
...,
 *  { ..., E, ... },
 };
@@ -32,7 +35,8 @@ identifier var, arr;
 expression E;
 @@
 (
-struct \(of_device_id \| i2c_device_id \| platform_device_id\) arr[] = {
+struct
+  \(of_device_id\|i2c_device_id\|platform_device_id\|dmi_system_id\) arr[] = {
...,
{
.var = E,
@@ -41,7 +45,8 @@ struct \(of_device_id \| i2c_device_id \| 
platform_device_id\) arr[] = {
 +  { }
 };
 |
-struct \(of_device_id \| i2c_device_id \| platform_device_id\) arr[] = {
+struct
+  \(of_device_id\|i2c_device_id\|platform_device_id\|dmi_system_id\) arr[] = {
...,
{ ..., E, ... },
 +  { },
@@ -54,7 +59,8 @@ identifier var, arr;
 expression E;
 @@
 (
-struct \(of_device_id \| i2c_device_id \| platform_device_id\) arr[] = {
+struct
+  \(of_device_id\|i2c_device_id\|platform_device_id\|dmi_system_id\) arr[] = {
...,
{
.var = E,
@@ -62,7 +68,8 @@ struct \(of_device_id \| i2c_device_id \| 
platform_device_id\) arr[] = {
@p1
 };
 |
-struct \(of_device_id \| i2c_device_id \| platform_device_id\) arr[] = {
+struct
+  \(of_device_id\|i2c_device_id\|platform_device_id\|dmi_system_id\) arr[] = {
...,
{ ..., E, ... }
@p1

undefined reference to `pps_unregister_source'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   238d1d0f79f619d75c2cc741d6770fb0986aef24
commit: ee84595a91c60d33cbf1d5b941b04a3ee6cf7ce0 afs, rxrpc: Update the 
MAINTAINERS file
date:   2 weeks ago
config: x86_64-randconfig-s1-01012230 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout ee84595a91c60d33cbf1d5b941b04a3ee6cf7ce0
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `ptp_clock_unregister':
>> (.text+0x40e0a5): undefined reference to `pps_unregister_source'
   drivers/built-in.o: In function `ptp_clock_unregister':
>> (.text+0x40e0cc): undefined reference to `posix_clock_unregister'
   drivers/built-in.o: In function `ptp_clock_event':
>> (.text+0x40e249): undefined reference to `pps_event'
   drivers/built-in.o: In function `ptp_clock_register':
>> (.text+0x40e5e1): undefined reference to `pps_register_source'
   drivers/built-in.o: In function `ptp_clock_register':
>> (.text+0x40e62c): undefined reference to `posix_clock_register'
   drivers/built-in.o: In function `ptp_clock_register':
   (.text+0x40e68d): undefined reference to `pps_unregister_source'

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


.config.gz
Description: application/gzip

[PATCH] firmware: google: add __ro_after_init to memconsole_bin_attr

[Bhumika Goyal]

The object memconsole_bin_attr of type bin_attribute structure is not
modified after getting initialized by memconsole_init. Apart from
getting referenced in init it is also passed as an argument to the
functions sysfs_{remove/create}_bin_file but both the arguments are of
type const struct bin_attribute *. Therefore add __ro_after_init to its
declaration.

Signed-off-by: Bhumika Goyal 
---
 drivers/firmware/google/memconsole.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/google/memconsole.c 
b/drivers/firmware/google/memconsole.c
index 2f569aa..54fa5a3 100644
--- a/drivers/firmware/google/memconsole.c
+++ b/drivers/firmware/google/memconsole.c
@@ -63,7 +63,7 @@ static ssize_t memconsole_read(struct file *filp, struct 
kobject *kobp,
return ret;
 }
 
-static struct bin_attribute memconsole_bin_attr = {
+static struct bin_attribute memconsole_bin_attr __ro_after_init = {
.attr = {.name = "log", .mode = 0444},
.read = memconsole_read,
 };
-- 
1.9.1

Re: [PATCH] scsi: mpt3sas: fix hang on ata passthru commands

[David Miller]

From: Bart Van Assche 
Date: Sun, 1 Jan 2017 14:22:11 +

> My recommendation is to revert commit 18f6084a989b ("scsi: mpt3sas: Fix
> secure erase premature termination"). Since the mpt3sas driver uses the
> single-queue approach and since the SCSI core unlocks the block layer
> request queue lock before the .queuecommand callback function is called,
> multiple threads can execute that callback function (scsih_qcmd() in this
> case) simultaneously. This means that using scsi_internal_device_block()
> from inside .queuecommand to serialize SCSI command execution is wrong.

But this causes a regression for the thing being fixed by that commit.

Why don't we figure out what that semantics that commit was trying to
achieve and implement that properly?

[PATCH 0/5] staging-Lustre: Fine-tuning for some function implementations

[SF Markus Elfring]

From: Markus Elfring 
Date: Sun, 1 Jan 2017 17:10:10 +0100

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (5):
  llite: Use seq_puts() in three functions
  mgc: Combine two seq_printf() calls into one call in lprocfs_mgc_rd_ir_state()
  obdclass: Use seq_putc() in four functions
  obdclass: Combine two seq_printf() calls into one call in lprocfs_rd_state()
  obdclass: Use seq_puts() in three functions

 drivers/staging/lustre/lustre/llite/lproc_llite.c  | 12 +--
 drivers/staging/lustre/lustre/mgc/mgc_request.c|  5 +
 drivers/staging/lustre/lustre/obdclass/cl_object.c |  8 
 .../lustre/lustre/obdclass/lprocfs_status.c| 23 ++
 4 files changed, 21 insertions(+), 27 deletions(-)

-- 
2.11.0

[PATCH 1/5] staging/lustre/llite: Use seq_puts() in three functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Sun, 1 Jan 2017 15:30:45 +0100

A string which did not contain a data format specification should be put
into a sequence. Thus use the corresponding function "seq_puts"
so that the data output will be a bit more efficient in these functions.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/staging/lustre/lustre/llite/lproc_llite.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/lproc_llite.c 
b/drivers/staging/lustre/lustre/llite/lproc_llite.c
index 03682c10fc9e..b195b7eb2883 100644
--- a/drivers/staging/lustre/lustre/llite/lproc_llite.c
+++ b/drivers/staging/lustre/lustre/llite/lproc_llite.c
@@ -1325,8 +1325,8 @@ static int ll_rw_extents_stats_pp_seq_show(struct 
seq_file *seq, void *v)
ktime_get_real_ts64(&now);
 
if (!sbi->ll_rw_stats_on) {
-   seq_printf(seq, "disabled\n"
-  "write anything in this file to activate, then 0 or 
\"[D/d]isabled\" to deactivate\n");
+   seq_puts(seq, "disabled\n"
+"write anything in this file to activate, then 0 or 
\"[D/d]isabled\" to deactivate\n");
return 0;
}
seq_printf(seq, "snapshot_time:  %llu.%09lu (secs.usecs)\n",
@@ -1403,8 +1403,8 @@ static int ll_rw_extents_stats_seq_show(struct seq_file 
*seq, void *v)
ktime_get_real_ts64(&now);
 
if (!sbi->ll_rw_stats_on) {
-   seq_printf(seq, "disabled\n"
-  "write anything in this file to activate, then 0 or 
\"[D/d]isabled\" to deactivate\n");
+   seq_puts(seq, "disabled\n"
+"write anything in this file to activate, then 0 or 
\"[D/d]isabled\" to deactivate\n");
return 0;
}
seq_printf(seq, "snapshot_time:  %llu.%09lu (secs.usecs)\n",
@@ -1583,8 +1583,8 @@ static int ll_rw_offset_stats_seq_show(struct seq_file 
*seq, void *v)
ktime_get_real_ts64(&now);
 
if (!sbi->ll_rw_stats_on) {
-   seq_printf(seq, "disabled\n"
-  "write anything in this file to activate, then 0 or 
\"[D/d]isabled\" to deactivate\n");
+   seq_puts(seq, "disabled\n"
+"write anything in this file to activate, then 0 or 
\"[D/d]isabled\" to deactivate\n");
return 0;
}
spin_lock(&sbi->ll_process_lock);
-- 
2.11.0

[PATCH 2/5] staging/lustre/mgc: Combine two seq_printf() calls into one call in lprocfs_mgc_rd_ir_state()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sun, 1 Jan 2017 15:40:29 +0100

Some data were printed into a sequence by two separate function calls.
Print the same data by a single function call instead.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/staging/lustre/lustre/mgc/mgc_request.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c 
b/drivers/staging/lustre/lustre/mgc/mgc_request.c
index b9c522a3c7a4..a6ca48d7e96b 100644
--- a/drivers/staging/lustre/lustre/mgc/mgc_request.c
+++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c
@@ -460,11 +460,8 @@ int lprocfs_mgc_rd_ir_state(struct seq_file *m, void *data)
 
imp = obd->u.cli.cl_import;
ocd = &imp->imp_connect_data;
-
-   seq_printf(m, "imperative_recovery: %s\n",
+   seq_printf(m, "imperative_recovery: %s\nclient_state:\n",
   OCD_HAS_FLAG(ocd, IMP_RECOV) ? "ENABLED" : "DISABLED");
-   seq_printf(m, "client_state:\n");
-
spin_lock(&config_list_lock);
list_for_each_entry(cld, &config_llog_list, cld_list_chain) {
if (!cld->cld_recover)
-- 
2.11.0

[PATCH] video: fbdev: maxinefb: add __initdata to maxinefb_fix

[Bhumika Goyal]

The object maxinefb_fix of type fb_fix_screeninfo is never referenced
after initialization by maxinefb_init. In the init function, the object
and one of its fields is only stored into another variable. So, the
object and its fields are never referenced anywhere after initialization
and therefore add __initdata to its declaration.

Signed-off-by: Bhumika Goyal 
---
 drivers/video/fbdev/maxinefb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/maxinefb.c b/drivers/video/fbdev/maxinefb.c
index 5cf52d3..cab7333 100644
--- a/drivers/video/fbdev/maxinefb.c
+++ b/drivers/video/fbdev/maxinefb.c
@@ -51,7 +51,7 @@
.vmode =FB_VMODE_NONINTERLACED,
 };
 
-static struct fb_fix_screeninfo maxinefb_fix = {
+static struct fb_fix_screeninfo maxinefb_fix __initdata = {
.id =   "Maxine",
.smem_len = (1024*768),
.type = FB_TYPE_PACKED_PIXELS,
-- 
1.9.1

[PATCH 3/5] staging/lustre/obdclass: Use seq_putc() in four functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Sun, 1 Jan 2017 16:12:23 +0100

A few single characters (line breaks) should be put into a sequence.
Thus use the corresponding function "seq_putc".

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/staging/lustre/lustre/obdclass/cl_object.c  | 4 ++--
 drivers/staging/lustre/lustre/obdclass/lprocfs_status.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/lustre/lustre/obdclass/cl_object.c 
b/drivers/staging/lustre/lustre/obdclass/cl_object.c
index f5d4e23c64b7..277908d66a89 100644
--- a/drivers/staging/lustre/lustre/obdclass/cl_object.c
+++ b/drivers/staging/lustre/lustre/obdclass/cl_object.c
@@ -441,7 +441,7 @@ static int cache_stats_print(const struct cache_stats *cs,
seq_printf(m, "%6s", " ");
for (i = 0; i < CS_NR; i++)
seq_printf(m, "%8s", names[i]);
-   seq_printf(m, "\n");
+   seq_putc(m, '\n');
}
 
seq_printf(m, "%5.5s:", cs->cs_name);
@@ -516,7 +516,7 @@ locks: .. .. .. .. .. [.. .. 
.. .. ..]
   atomic_read(&site->cs_pages_state[i]));
seq_printf(m, "]\n");
cache_stats_print(&cl_env_stats, m, 0);
-   seq_printf(m, "\n");
+   seq_putc(m, '\n');
return 0;
 }
 EXPORT_SYMBOL(cl_site_stats_print);
diff --git a/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c 
b/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
index 2c99717b0aba..3f6fcab5a1fc 100644
--- a/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
+++ b/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
@@ -878,7 +878,7 @@ int lprocfs_at_hist_helper(struct seq_file *m, struct 
adaptive_timeout *at)
 
for (i = 0; i < AT_BINS; i++)
seq_printf(m, "%3u ", at->at_hist[i]);
-   seq_printf(m, "\n");
+   seq_putc(m, '\n');
return 0;
 }
 EXPORT_SYMBOL(lprocfs_at_hist_helper);
@@ -946,7 +946,7 @@ int lprocfs_rd_connect_flags(struct seq_file *m, void *data)
flags = obd->u.cli.cl_import->imp_connect_data.ocd_connect_flags;
seq_printf(m, "flags=%#llx\n", flags);
obd_connect_seq_flags2str(m, flags, "\n");
-   seq_printf(m, "\n");
+   seq_putc(m, '\n');
up_read(&obd->u.cli.cl_sem);
return 0;
 }
-- 
2.11.0

[PATCH 4/5] staging/lustre/obdclass: Combine two seq_printf() calls into one call in lprocfs_rd_state()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sun, 1 Jan 2017 16:26:36 +0100

Some data were printed into a sequence by two separate function calls.
Print the same data by a single function call instead.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/staging/lustre/lustre/obdclass/lprocfs_status.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c 
b/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
index 3f6fcab5a1fc..a167cbe8a50e 100644
--- a/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
+++ b/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
@@ -853,10 +853,8 @@ int lprocfs_rd_state(struct seq_file *m, void *data)
return rc;
 
imp = obd->u.cli.cl_import;
-
-   seq_printf(m, "current_state: %s\n",
+   seq_printf(m, "current_state: %s\nstate_history:\n",
   ptlrpc_import_state_name(imp->imp_state));
-   seq_printf(m, "state_history:\n");
k = imp->imp_state_hist_idx;
for (j = 0; j < IMP_STATE_HIST_LEN; j++) {
struct import_state_hist *ish =
-- 
2.11.0

[PATCH 5/5] staging/lustre/obdclass: Use seq_puts() in three functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Sun, 1 Jan 2017 16:45:32 +0100

A string which did not contain a data format specification should be put
into a sequence. Thus use the corresponding function "seq_puts"
so that the data output will be a bit more efficient in these functions.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/staging/lustre/lustre/obdclass/cl_object.c  |  4 ++--
 drivers/staging/lustre/lustre/obdclass/lprocfs_status.c | 15 +++
 2 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/lustre/lustre/obdclass/cl_object.c 
b/drivers/staging/lustre/lustre/obdclass/cl_object.c
index 277908d66a89..3e00aa4747b8 100644
--- a/drivers/staging/lustre/lustre/obdclass/cl_object.c
+++ b/drivers/staging/lustre/lustre/obdclass/cl_object.c
@@ -510,11 +510,11 @@ locks: .. .. .. .. .. [.. .. 
.. .. ..]
  */
lu_site_stats_print(&site->cs_lu, m);
cache_stats_print(&site->cs_pages, m, 1);
-   seq_printf(m, " [");
+   seq_puts(m, " [");
for (i = 0; i < ARRAY_SIZE(site->cs_pages_state); ++i)
seq_printf(m, "%s: %u ", pstate[i],
   atomic_read(&site->cs_pages_state[i]));
-   seq_printf(m, "]\n");
+   seq_puts(m, "]\n");
cache_stats_print(&cl_env_stats, m, 0);
seq_putc(m, '\n');
return 0;
diff --git a/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c 
b/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
index a167cbe8a50e..3ce590cdd957 100644
--- a/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
+++ b/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
@@ -649,7 +649,7 @@ static int obd_import_flags2str(struct obd_import *imp, 
struct seq_file *m)
bool first = true;
 
if (imp->imp_obd->obd_no_recov) {
-   seq_printf(m, "no_recov");
+   seq_puts(m, "no_recov");
first = false;
}
 
@@ -715,15 +715,14 @@ int lprocfs_rd_import(struct seq_file *m, void *data)
   imp->imp_connect_data.ocd_instance);
obd_connect_seq_flags2str(m, imp->imp_connect_data.ocd_connect_flags,
  ", ");
-   seq_printf(m, " ]\n");
+   seq_puts(m, " ]\n");
obd_connect_data_seqprint(m, ocd);
-   seq_printf(m, "import_flags: [ ");
+   seq_puts(m, "import_flags: [ ");
obd_import_flags2str(imp, m);
-
-   seq_printf(m,
-  " ]\n"
-  "connection:\n"
-  "   failover_nids: [ ");
+   seq_puts(m,
+" ]\n"
+"connection:\n"
+"   failover_nids: [ ");
spin_lock(&imp->imp_lock);
j = 0;
list_for_each_entry(conn, &imp->imp_conn_list, oic_item) {
-- 
2.11.0

arch/xtensa/include/asm/initialize_mmu.h:41: Error: invalid register 'atomctl' for 'wsr' instruction

[kbuild test robot]

Hi Pete,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   238d1d0f79f619d75c2cc741d6770fb0986aef24
commit: d0b73b488c55df905ea8faaad079f8535629ed26 xtensa: Add config files for 
Diamond 233L - Rev C processor variant
date:   3 years, 10 months ago
config: xtensa-generic_kc705_defconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout d0b73b488c55df905ea8faaad079f8535629ed26
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All errors (new ones prefixed by >>):

   arch/xtensa/include/asm/initialize_mmu.h: Assembler messages:
>> arch/xtensa/include/asm/initialize_mmu.h:41: Error: invalid register 
>> 'atomctl' for 'wsr' instruction

vim +41 arch/xtensa/include/asm/initialize_mmu.h

c622b29d Max Filippov 2012-11-19  25  
c622b29d Max Filippov 2012-11-19  26  #ifdef __ASSEMBLY__
c622b29d Max Filippov 2012-11-19  27  
c622b29d Max Filippov 2012-11-19  28  #define XTENSA_HWVERSION_RC_2009_0 23
c622b29d Max Filippov 2012-11-19  29  
c622b29d Max Filippov 2012-11-19  30.macro  initialize_mmu
c622b29d Max Filippov 2012-11-19  31  
c622b29d Max Filippov 2012-11-19  32  #if XCHAL_HAVE_S32C1I && 
(XCHAL_HW_MIN_VERSION >= XTENSA_HWVERSION_RC_2009_0)
c622b29d Max Filippov 2012-11-19  33  /*
c622b29d Max Filippov 2012-11-19  34   * We Have Atomic Operation Control 
(ATOMCTL) Register; Initialize it.
c622b29d Max Filippov 2012-11-19  35   * For details see 
Documentation/xtensa/atomctl.txt
c622b29d Max Filippov 2012-11-19  36   */
c622b29d Max Filippov 2012-11-19  37  #if XCHAL_DCACHE_IS_COHERENT
c622b29d Max Filippov 2012-11-19  38movia3, 0x25/* For SMP/MX 
-- internal for writeback,
c622b29d Max Filippov 2012-11-19  39 * RCW otherwise
c622b29d Max Filippov 2012-11-19  40 */
c622b29d Max Filippov 2012-11-19 @41  #else
c622b29d Max Filippov 2012-11-19  42movia3, 0x29/* non-MX -- 
Most cores use Std Memory
c622b29d Max Filippov 2012-11-19  43 * Controlers 
which usually can't use RCW
c622b29d Max Filippov 2012-11-19  44 */
c622b29d Max Filippov 2012-11-19  45  #endif
c622b29d Max Filippov 2012-11-19  46wsr a3, atomctl
c622b29d Max Filippov 2012-11-19  47  #endif  /* XCHAL_HAVE_S32C1I &&
c622b29d Max Filippov 2012-11-19  48 * (XCHAL_HW_MIN_VERSION >= 
XTENSA_HWVERSION_RC_2009_0)
c622b29d Max Filippov 2012-11-19  49 */

:: The code at line 41 was first introduced by commit
:: c622b29d1f38021411965b7e0170ab01b257 xtensa: initialize atomctl SR

:: TO: Max Filippov 
:: CC: Chris Zankel 

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


.config.gz
Description: application/gzip

arch/mips/vdso/elf.S:1:0: error: '-march=r3000' requires '-mfp32'

[kbuild test robot]

Hi Alex,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   238d1d0f79f619d75c2cc741d6770fb0986aef24
commit: ebb5e78cc63417a35254a791de66e1cc84f963cc MIPS: Initial implementation 
of a VDSO
date:   1 year, 2 months ago
config: mips-decstation_defconfig (attached as .config)
compiler: mipsel-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ebb5e78cc63417a35254a791de66e1cc84f963cc
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> arch/mips/vdso/elf.S:1:0: error: '-march=r3000' requires '-mfp32'
/*

--
>> arch/mips/vdso/sigreturn.S:1:0: error: '-march=r3000' requires '-mfp32'
/*


vim +1 arch/mips/vdso/elf.S

   > 1  /*
 2   * Copyright (C) 2015 Imagination Technologies
 3   * Author: Alex Smith 
 4   *

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


.config.gz
Description: application/gzip

Re: Stopping watchdog in watchdog driver remove functions

[Guenter Roeck]

On 01/01/2017 03:14 AM, Wim Van Sebroeck wrote:

Hi Guenter,


I noticed that several watchdog drivers stop the watchdog in trhe driver
remove function.
A non-exhaustive list of drivers doing that is

drivers/watchdog/bcm7038_wdt.c
drivers/watchdog/cadence_wdt.c
drivers/watchdog/imgpdc_wdt.c
drivers/watchdog/jz4740_wdt.c
drivers/watchdog/kempld_wdt.c
drivers/watchdog/max77620_wdt.c
drivers/watchdog/moxart_wdt.c
drivers/watchdog/sama5d4_wdt.c
drivers/watchdog/tangox_wdt.c
drivers/watchdog/tegra_wdt.c

Since a watchdog has to be closed for its driver to be removable, one
situation
where a watchdog is still running on unload is where the watchdog was
opened but
not closed properly (eg by killing the watchdog application, or if the
'nowayout'
flag is set).

Given that, does it even make sense to stop the watchdog in the remove
function ?
Should it even be permitted ?



From an API point of view: if WDIOF_MAGICCLOSE is being used then the watchdog

_SHOULD_ continue to run when the watchdog was not properly closed (which
normally also results in a reboot of the system).
if WDIOF_MAGICCLOSE is not being used then closing the watchdog device means
that the driver needs to stop the watchdog.


All the above have WDIOF_MAGICCLOSE set. Does that mean they should not stop
the watchdog on remove ?

Happy new year everyone !

Guenter

Re: [PATCH] net: socket: don't set sk_uid to garbage value in ->setattr()

[David Miller]

From: Lorenzo Colitti 
Date: Sun, 1 Jan 2017 16:57:23 +0900

> On Sat, Dec 31, 2016 at 8:42 AM, Eric Biggers  wrote:
>> ->setattr() was recently implemented for socket files to sync the socket
>> inode's uid to the new 'sk_uid' member of struct sock.  It does this by
>> copying over the ia_uid member of struct iattr.  However, ia_uid is
>> actually only valid when ATTR_UID is set in ia_valid, indicating that
>> the uid is being changed, e.g. by chown.
>> [...]
>> -   if (!err) {
>> +   if (!err && (iattr->ia_valid & ATTR_UID)) {
> 
> Oops. Thanks for fixing this. Unit tested in
> https://android-review.googlesource.com/316594 .
> 
> Tested-by: Lorenzo Colitti 
> Acked-by: Lorenzo Colitti 

Applied, thanks everyone.

Re: [PATCH] net: stmmac: remove unused duplicate property snps,axi_all

[David Miller]

From: Niklas Cassel 
Date: Fri, 30 Dec 2016 13:56:46 +0100

> From: Niklas Cassel 
> 
> For core revision 3.x Address-Aligned Beats is available in two registers.
> The DT property snps,aal was created for AAL in the DMA bus register,
> which is a read/write bit.
> The DT property snps,axi_all was created for AXI_AAL in the AXI bus mode
> register, which is a read only bit that reflects the value of AAL in the
> DMA bus register.
> 
> Since the value of snps,axi_all is never used in the driver,
> and since the property was created for a bit that is read only,
> it should be safe to remove the property.
> 
> Acked-by: Giuseppe Cavallaro 
> Signed-off-by: Niklas Cassel 

Applied to net-next, thanks.

arch/mips/vdso/gettimeofday.c:1:0: error: '-march=r3900' requires '-mfp32'

[kbuild test robot]

Hi Guenter,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   238d1d0f79f619d75c2cc741d6770fb0986aef24
commit: 398c7500a1f5f74e207bd2edca1b1721b3cc1f1e MIPS: VDSO: Fix build error 
with binutils 2.24 and earlier
date:   1 year ago
config: mips-jmr3927_defconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 398c7500a1f5f74e207bd2edca1b1721b3cc1f1e
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> arch/mips/vdso/gettimeofday.c:1:0: error: '-march=r3900' requires '-mfp32'
/*


vim +1 arch/mips/vdso/gettimeofday.c

a7f4df4e Alex Smith 2015-10-21 @1  /*
a7f4df4e Alex Smith 2015-10-21  2   * Copyright (C) 2015 Imagination 
Technologies
a7f4df4e Alex Smith 2015-10-21  3   * Author: Alex Smith 
a7f4df4e Alex Smith 2015-10-21  4   *
a7f4df4e Alex Smith 2015-10-21  5   * This program is free software; you can 
redistribute it and/or modify it
a7f4df4e Alex Smith 2015-10-21  6   * under the terms of the GNU General Public 
License as published by the
a7f4df4e Alex Smith 2015-10-21  7   * Free Software Foundation;  either version 
2 of the  License, or (at your
a7f4df4e Alex Smith 2015-10-21  8   * option) any later version.
a7f4df4e Alex Smith 2015-10-21  9   */

:: The code at line 1 was first introduced by commit
:: a7f4df4e21dd8a8dab96e88acd2c9c5017b83fc6 MIPS: VDSO: Add implementations 
of gettimeofday() and clock_gettime()

:: TO: Alex Smith 
:: CC: Ralf Baechle 

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


.config.gz
Description: application/gzip

Re: Still OOM problems with 4.9er kernels

[Gerhard Wiesinger]

On 23.12.2016 03:55, Minchan Kim wrote:

On Fri, Dec 09, 2016 at 04:52:07PM +0100, Gerhard Wiesinger wrote:

On 09.12.2016 14:40, Michal Hocko wrote:

On Fri 09-12-16 08:06:25, Gerhard Wiesinger wrote:

Hello,

same with latest kernel rc, dnf still killed with OOM (but sometimes
better).

./update.sh: line 40:  1591 Killed  ${EXE} update ${PARAMS}
(does dnf clean all;dnf update)
Linux database.intern 4.9.0-0.rc8.git2.1.fc26.x86_64 #1 SMP Wed Dec 7
17:53:29 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Updated bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1314697

Could you post your oom report please?

E.g. a new one with more than one included, first one after boot ...

Just setup a low mem VM under KVM and it is easily triggerable.

Still enough virtual memory available ...

4.9.0-0.rc8.git2.1.fc26.x86_64

[  624.862777] ksoftirqd/0: page allocation failure: order:0,
mode:0x2080020(GFP_ATOMIC)
[  624.863319] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted
4.9.0-0.rc8.git2.1.fc26.x86_64 #1
[  624.863410] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.9.3
[  624.863510]  aa62c007f958 904774e3 90c7dd98

[  624.863923]  aa62c007f9e0 9020e6ea 020800200246
90c7dd98
[  624.864019]  aa62c007f980 96b90010 aa62c007f9f0
aa62c007f9a0
[  624.864998] Call Trace:
[  624.865149]  [] dump_stack+0x86/0xc3
[  624.865347]  [] warn_alloc+0x13a/0x170
[  624.865432]  [] __alloc_pages_slowpath+0x252/0xbb0
[  624.865563]  [] __alloc_pages_nodemask+0x40d/0x4b0
[  624.865675]  [] __alloc_page_frag+0x193/0x200
[  624.866024]  [] __napi_alloc_skb+0x8e/0xf0
[  624.866113]  [] page_to_skb.isra.28+0x5d/0x310
[virtio_net]
[  624.866201]  [] virtnet_receive+0x2db/0x9a0
[virtio_net]
[  624.867378]  [] virtnet_poll+0x1d/0x80 [virtio_net]
[  624.867494]  [] net_rx_action+0x23e/0x470
[  624.867612]  [] __do_softirq+0xcd/0x4b9
[  624.867704]  [] ? smpboot_thread_fn+0x34/0x1f0
[  624.867833]  [] ? smpboot_thread_fn+0x12d/0x1f0
[  624.867924]  [] run_ksoftirqd+0x25/0x80
[  624.868109]  [] smpboot_thread_fn+0x128/0x1f0
[  624.868197]  [] ? sort_range+0x30/0x30
[  624.868596]  [] kthread+0x102/0x120
[  624.868679]  [] ? wait_for_completion+0x110/0x140
[  624.868768]  [] ? kthread_park+0x60/0x60
[  624.868850]  [] ret_from_fork+0x2a/0x40
[  843.528656] httpd (2490) used greatest stack depth: 10304 bytes left
[  878.077750] httpd (2976) used greatest stack depth: 10096 bytes left
[93918.861109] netstat (14579) used greatest stack depth: 9488 bytes left
[94050.874669] kworker/dying (6253) used greatest stack depth: 9008 bytes
left
[95895.765570] kworker/1:1H: page allocation failure: order:0,
mode:0x2280020(GFP_ATOMIC|__GFP_NOTRACK)
[95895.765819] CPU: 1 PID: 440 Comm: kworker/1:1H Not tainted
4.9.0-0.rc8.git2.1.fc26.x86_64 #1
[95895.765911] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.9.3
[95895.766060] Workqueue: kblockd blk_mq_run_work_fn
[95895.766143]  aa62c0257628 904774e3 90c7dd98

[95895.766235]  aa62c02576b0 9020e6ea 022800200046
90c7dd98
[95895.766325]  aa62c0257650 96b90010 aa62c02576c0
aa62c0257670
[95895.766417] Call Trace:
[95895.766502]  [] dump_stack+0x86/0xc3
[95895.766596]  [] warn_alloc+0x13a/0x170
[95895.766681]  [] __alloc_pages_slowpath+0x252/0xbb0
[95895.766767]  [] __alloc_pages_nodemask+0x40d/0x4b0
[95895.766866]  [] alloc_pages_current+0xa1/0x1f0
[95895.766971]  [] ? _raw_spin_unlock+0x27/0x40
[95895.767073]  [] new_slab+0x316/0x7c0
[95895.767160]  [] ___slab_alloc+0x3fb/0x5c0
[95895.772611]  [] ? cpuacct_charge+0xf2/0x1f0
[95895.773406]  [] ? alloc_indirect.isra.11+0x1d/0x50
[virtio_ring]
[95895.774327]  [] ? rcu_read_lock_sched_held+0x45/0x80
[95895.775212]  [] ? alloc_indirect.isra.11+0x1d/0x50
[virtio_ring]
[95895.776155]  [] __slab_alloc+0x51/0x90
[95895.777090]  [] __kmalloc+0x251/0x320
[95895.781502]  [] ? alloc_indirect.isra.11+0x1d/0x50
[virtio_ring]
[95895.782309]  [] alloc_indirect.isra.11+0x1d/0x50
[virtio_ring]
[95895.783334]  [] virtqueue_add_sgs+0x1c3/0x4a0
[virtio_ring]
[95895.784059]  [] ? kvm_sched_clock_read+0x25/0x40
[95895.784742]  [] __virtblk_add_req+0xbc/0x220
[virtio_blk]
[95895.785419]  [] ? debug_lockdep_rcu_enabled+0x1d/0x20
[95895.786086]  [] ? virtio_queue_rq+0x105/0x290
[virtio_blk]
[95895.786750]  [] virtio_queue_rq+0x12d/0x290
[virtio_blk]
[95895.787427]  [] __blk_mq_run_hw_queue+0x26d/0x3b0
[95895.788106]  [] blk_mq_run_work_fn+0x12/0x20
[95895.789065]  [] process_one_work+0x23e/0x6f0
[95895.789741]  [] ? process_one_work+0x1ba/0x6f0
[95895.790444]  [] worker_thread+0x4e/0x490
[95895.791178]  [] ? process_one_work+0x6f0/0x6f0
[95895.791911]  [] ? process_one_work+0x6f0/0x6f0
[95895.792653]  [] ? do_syscall_64+0x6c/0x1f0
[95895.793397]  [] kthread+0x102/0x120
[95895.794212]  [] ? trace_hardirqs_on_caller+0xf5/0x1b0
[95895.794942]  [] ? kthread_park+0x60/0x60
[95895.795689]  [] ret_from

Re: [BUG] 4.9 - kernel oops when pptp connection is established and the kernel doesn't have pptp modules compiled

[Ian Kumlien]

On Fri, Dec 30, 2016 at 11:48 PM, Ian Kumlien  wrote:
> Hi,
>
> Been fighting with "crash" to get it to help me to analyze my crash
> dumps... This is the output from vmcore-dmesg.
>
> This is 100% reproducible...
>
> Config that lets the connection trough but crashes the kernel:
> # CONFIG_NF_CONNTRACK_PPTP is not set
> # CONFIG_NF_NAT_PPTP is not set
> CONFIG_PPTP=y
>
> If I enable the *_NF_* options, it doesn't crash but it also blocks
> the PPTP packets.
>
> The crash is after the negotiation bit...

So, some of the dumps pointed me, after some coaxing, to
net/core/flow_dissector.c:448
---
ppp_hdr = skb_header_pointer(skb, nhoff + offset,
 sizeof(_ppp_hdr),
_ppp_hdr);
if (!ppp_hdr)
goto out_bad;
--

Ie, copy or get the information from the skb to get more information
on the pptp connection.

However include/linux/skbuff.h:3109, with my test and debug code added
static inline void * __must_check
__skb_header_pointer(const struct sk_buff *skb, int offset,
 int len, void *data, int hlen, void *buffer)
{
if (hlen - offset >= len)
{
if (skb == NULL || data == NULL)
{
printk("WARNING: something is null skb:%p
data:%p - offset: %i hlen: %i len: %i\n", skb, data, offset, hlen,
len);
return NULL;
}
else
return data + offset;
}

if (!skb ||
skb_copy_bits(skb, offset, buffer, len) < 0)
return NULL;

return buffer;
}

static inline void * __must_check
skb_header_pointer(const struct sk_buff *skb, int offset, int len, void *buffer)
{
return __skb_header_pointer(skb, offset, len, skb->data,
skb_headlen(skb), buffer);
}
---

so skb_header_pointer sends skb->data as data, but we never check if
skb is *NULL*

This does happen when we do a pptp connection:
[   89.606712] WARNING: something is null skb:  (null)
data:88bccc0d4000 - offset: 14 hlen: 256 len: 20
[   89.613264] WARNING: something is null skb:  (null)
data:88bccc00f800 - offset: 14 hlen: 256 len: 20
[   89.621005] WARNING: something is null skb:  (null)
data:88bccc010800 - offset: 14 hlen: 256 len: 20
[   89.650479] WARNING: something is null skb:  (null)
data:88bccc2cb000 - offset: 14 hlen: 256 len: 20

So, the question is if the skb should always be there and always be
valid? In that case something like this should fix it:
static inline void * __must_check
__skb_header_pointer(const struct sk_buff *skb, int offset,
 int len, void *data, int hlen, void *buffer)
{
if (!skb)
return NULL;

if (hlen - offset >= len)
return data + offset;

if (skb_copy_bits(skb, offset, buffer, len) < 0)
return NULL;

return buffer;
}
---

Else the actual check would have to be moved to skb_header_pointer in
this case - comments?

> [  109.556866] BUG: unable to handle kernel NULL pointer dereference
> at 0080
> [  109.557102] IP: [] __skb_flow_dissect+0xa88/0xce0
> [  109.557263] PGD 0
> [  109.557338]
> [  109.557484] Oops:  [#1] SMP
> [  109.557562] Modules linked in: chaoskey
> [  109.557783] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.9.0 #79
> [  109.557867] Hardware name: Supermicro
> A1SRM-LN7F/LN5F/A1SRM-LN7F-2758, BIOS 1.0c 11/04/2015
> [  109.557957] task: 94085c27bc00 task.stack: b745c0068000
> [  109.558041] RIP: 0010:[]  []
> __skb_flow_dissect+0xa88/0xce0
> [  109.558203] RSP: 0018:94087fc83d40  EFLAGS: 00010206
> [  109.558286] RAX: 0130 RBX: 8975bf80 RCX: 
> 94084fab6800
> [  109.558373] RDX: 0010 RSI: 000c RDI: 
> 
> [  109.558460] RBP: 0b88 R08:  R09: 
> 0022
> [  109.558547] R10: 0008 R11: 94087fc83e04 R12: 
> 
> [  109.558763] R13: 94084fab6800 R14: 94087fc83e04 R15: 
> 002f
> [  109.558979] FS:  () GS:94087fc8()
> knlGS:
> [  109.559326] CS:  0010 DS:  ES:  CR0: 80050033
> [  109.559539] CR2: 0080 CR3: 000281809000 CR4: 
> 001026e0
> [  109.559753] Stack:
> [  109.559957]  000c 94084fab6822 0001
> 94085c2b5fc0
> [  109.560578]  0001 2000 
> 
> [  109.561200]    
> 
> [  109.561820] Call Trace:
> [  109.562027]  
> [  109.562108]  [] ? eth_get_headlen+0x7a/0xf0
> [  109.562522]  [] ? igb_poll+0x96a/0xe80
> [  109.562737]  [] ? net_rx_action+0x20b/0x350
> [  109.562953]  [] ? __do_softirq+0xe8/0x280
> [  10

Re: [PATCH] scsi: mpt3sas: fix hang on ata passthru commands

[James Bottomley]

On Sun, 2017-01-01 at 11:33 -0500, David Miller wrote:
> From: Bart Van Assche 
> Date: Sun, 1 Jan 2017 14:22:11 +
> 
> > My recommendation is to revert commit 18f6084a989b ("scsi: mpt3sas: Fix
> > secure erase premature termination"). Since the mpt3sas driver uses the
> > single-queue approach and since the SCSI core unlocks the block layer
> > request queue lock before the .queuecommand callback function is called,
> > multiple threads can execute that callback function (scsih_qcmd() in this
> > case) simultaneously. This means that using scsi_internal_device_block()
> > from inside .queuecommand to serialize SCSI command execution is wrong.
> 
> But this causes a regression for the thing being fixed by that
> commit.

Right, we don't do that; that's why I didn't list it as one of the
options.

> Why don't we figure out what that semantics that commit was trying to
> achieve and implement that properly?

Now that I look at the reviews, each of the reviewers said what the
correct thing to do was: return SAM_STAT_BUSY if SATL commands are
outstanding like the spec says.  You all get negative brownie points
for not insisting on a rework.

Does this patch (compile tested only) fix the problems for everyone?

James

---

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 394fe13..0983a65 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -393,6 +393,7 @@ struct MPT3SAS_TARGET {
  * @eedp_enable: eedp support enable bit
  * @eedp_type: 0(type_1), 1(type_2), 2(type_3)
  * @eedp_block_length: block size
+ * @ata_command_pending: SATL passthrough outstanding for device
  */
 struct MPT3SAS_DEVICE {
struct MPT3SAS_TARGET *sas_target;
@@ -404,6 +405,17 @@ struct MPT3SAS_DEVICE {
u8  ignore_delay_remove;
/* Iopriority Command Handling */
u8  ncq_prio_enable;
+   /*
+* Bug workaround for SATL handling: the mpt2/3sas firmware
+* doesn't return BUSY or TASK_SET_FULL for subsequent
+* commands while a SATL pass through is in operation as the
+* spec requires, it simply does nothing with them until the
+* pass through completes, causing them possibly to timeout if
+* the passthrough is a long executing command (like format or
+* secure erase).  This variable allows us to do the right
+* thing while a SATL command is pending.
+*/
+   u8 ata_command_pending;
 
 };
 
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index b5c966e..1446a0a 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -3899,9 +3899,12 @@ _scsih_temp_threshold_events(struct MPT3SAS_ADAPTER *ioc,
}
 }
 
-static inline bool ata_12_16_cmd(struct scsi_cmnd *scmd)
+static void set_satl_pending(struct scsi_cmnd *scmd, bool pending)
 {
-   return (scmd->cmnd[0] == ATA_12 || scmd->cmnd[0] == ATA_16);
+   struct MPT3SAS_DEVICE *priv = scmd->device->hostdata;
+
+   if  (scmd->cmnd[0] == ATA_12 || scmd->cmnd[0] == ATA_16)
+   priv->ata_command_pending = pending;
 }
 
 /**
@@ -3925,9 +3928,7 @@ _scsih_flush_running_cmds(struct MPT3SAS_ADAPTER *ioc)
if (!scmd)
continue;
count++;
-   if (ata_12_16_cmd(scmd))
-   scsi_internal_device_unblock(scmd->device,
-   SDEV_RUNNING);
+   set_satl_pending(scmd, false);
mpt3sas_base_free_smid(ioc, smid);
scsi_dma_unmap(scmd);
if (ioc->pci_error_recovery)
@@ -4063,13 +4064,6 @@ scsih_qcmd(struct Scsi_Host *shost, struct scsi_cmnd 
*scmd)
if (ioc->logging_level & MPT_DEBUG_SCSI)
scsi_print_command(scmd);
 
-   /*
-* Lock the device for any subsequent command until command is
-* done.
-*/
-   if (ata_12_16_cmd(scmd))
-   scsi_internal_device_block(scmd->device);
-
sas_device_priv_data = scmd->device->hostdata;
if (!sas_device_priv_data || !sas_device_priv_data->sas_target) {
scmd->result = DID_NO_CONNECT << 16;
@@ -4083,6 +4077,16 @@ scsih_qcmd(struct Scsi_Host *shost, struct scsi_cmnd 
*scmd)
return 0;
}
 
+   /*
+* Bug work around for firmware SATL handling
+*/
+   if (sas_device_priv_data->ata_command_pending) {
+   scmd->result = SAM_STAT_BUSY;
+   scmd->scsi_done(scmd);
+   return 0;
+   }
+   set_satl_pending(scmd, true);
+
sas_target_priv_data = sas_device_priv_data->sas_target;
 
/* invalid device handle */
@@ -4650,8 +4654,7 @@ _scsih_io_done(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 
msix_index, u32 reply)
if (scmd == NULL)
return 1;
 
-   if (ata_12_16_cmd(scmd))
-  

cc1: error: '-march=r3900' requires '-mfp32'

[kbuild test robot]

Hi James,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   238d1d0f79f619d75c2cc741d6770fb0986aef24
commit: 034827c727f7f3946a18355b63995b402c226c82 MIPS: Fix -mabi=64 build of 
vdso.lds
date:   3 months ago
config: mips-jmr3927_defconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 034827c727f7f3946a18355b63995b402c226c82
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> cc1: error: '-march=r3900' requires '-mfp32'

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


.config.gz
Description: application/gzip

[PATCH v2 1/2] net: mdio: add mdio45_ethtool_ksettings_get

[Philippe Reynes]

There is a function in mdio for the old ethtool api gset.
We add a new function mdio45_ethtool_ksettings_get for the
new ethtool api glinksettings.

Signed-off-by: Philippe Reynes 
---
Changelog:
v2:
- simplify the code of ef4_ethtool_get_link_ksettings
  (feedback from Bert Kenward)

 drivers/net/mdio.c   |  178 ++
 include/linux/mdio.h |   21 ++
 2 files changed, 199 insertions(+), 0 deletions(-)

diff --git a/drivers/net/mdio.c b/drivers/net/mdio.c
index 3e027ed..077364c 100644
--- a/drivers/net/mdio.c
+++ b/drivers/net/mdio.c
@@ -342,6 +342,184 @@ void mdio45_ethtool_gset_npage(const struct mdio_if_info 
*mdio,
 EXPORT_SYMBOL(mdio45_ethtool_gset_npage);
 
 /**
+ * mdio45_ethtool_ksettings_get_npage - get settings for ETHTOOL_GLINKSETTINGS
+ * @mdio: MDIO interface
+ * @cmd: Ethtool request structure
+ * @npage_adv: Modes currently advertised on next pages
+ * @npage_lpa: Modes advertised by link partner on next pages
+ *
+ * The @cmd parameter is expected to have been cleared before calling
+ * mdio45_ethtool_ksettings_get_npage().
+ *
+ * Since the CSRs for auto-negotiation using next pages are not fully
+ * standardised, this function does not attempt to decode them.  The
+ * caller must pass them in.
+ */
+void mdio45_ethtool_ksettings_get_npage(const struct mdio_if_info *mdio,
+   struct ethtool_link_ksettings *cmd,
+   u32 npage_adv, u32 npage_lpa)
+{
+   int reg;
+   u32 speed, supported = 0, advertising = 0, lp_advertising = 0;
+
+   BUILD_BUG_ON(MDIO_SUPPORTS_C22 != ETH_MDIO_SUPPORTS_C22);
+   BUILD_BUG_ON(MDIO_SUPPORTS_C45 != ETH_MDIO_SUPPORTS_C45);
+
+   cmd->base.phy_address = mdio->prtad;
+   cmd->base.mdio_support =
+   mdio->mode_support & (MDIO_SUPPORTS_C45 | MDIO_SUPPORTS_C22);
+
+   reg = mdio->mdio_read(mdio->dev, mdio->prtad, MDIO_MMD_PMAPMD,
+ MDIO_CTRL2);
+   switch (reg & MDIO_PMA_CTRL2_TYPE) {
+   case MDIO_PMA_CTRL2_10GBT:
+   case MDIO_PMA_CTRL2_1000BT:
+   case MDIO_PMA_CTRL2_100BTX:
+   case MDIO_PMA_CTRL2_10BT:
+   cmd->base.port = PORT_TP;
+   supported = SUPPORTED_TP;
+   reg = mdio->mdio_read(mdio->dev, mdio->prtad, MDIO_MMD_PMAPMD,
+ MDIO_SPEED);
+   if (reg & MDIO_SPEED_10G)
+   supported |= SUPPORTED_1baseT_Full;
+   if (reg & MDIO_PMA_SPEED_1000)
+   supported |= (SUPPORTED_1000baseT_Full |
+   SUPPORTED_1000baseT_Half);
+   if (reg & MDIO_PMA_SPEED_100)
+   supported |= (SUPPORTED_100baseT_Full |
+   SUPPORTED_100baseT_Half);
+   if (reg & MDIO_PMA_SPEED_10)
+   supported |= (SUPPORTED_10baseT_Full |
+   SUPPORTED_10baseT_Half);
+   advertising = ADVERTISED_TP;
+   break;
+
+   case MDIO_PMA_CTRL2_10GBCX4:
+   cmd->base.port = PORT_OTHER;
+   supported = 0;
+   advertising = 0;
+   break;
+
+   case MDIO_PMA_CTRL2_10GBKX4:
+   case MDIO_PMA_CTRL2_10GBKR:
+   case MDIO_PMA_CTRL2_1000BKX:
+   cmd->base.port = PORT_OTHER;
+   supported = SUPPORTED_Backplane;
+   reg = mdio->mdio_read(mdio->dev, mdio->prtad, MDIO_MMD_PMAPMD,
+ MDIO_PMA_EXTABLE);
+   if (reg & MDIO_PMA_EXTABLE_10GBKX4)
+   supported |= SUPPORTED_1baseKX4_Full;
+   if (reg & MDIO_PMA_EXTABLE_10GBKR)
+   supported |= SUPPORTED_1baseKR_Full;
+   if (reg & MDIO_PMA_EXTABLE_1000BKX)
+   supported |= SUPPORTED_1000baseKX_Full;
+   reg = mdio->mdio_read(mdio->dev, mdio->prtad, MDIO_MMD_PMAPMD,
+ MDIO_PMA_10GBR_FECABLE);
+   if (reg & MDIO_PMA_10GBR_FECABLE_ABLE)
+   supported |= SUPPORTED_1baseR_FEC;
+   advertising = ADVERTISED_Backplane;
+   break;
+
+   /* All the other defined modes are flavours of optical */
+   default:
+   cmd->base.port = PORT_FIBRE;
+   supported = SUPPORTED_FIBRE;
+   advertising = ADVERTISED_FIBRE;
+   break;
+   }
+
+   if (mdio->mmds & MDIO_DEVS_AN) {
+   supported |= SUPPORTED_Autoneg;
+   reg = mdio->mdio_read(mdio->dev, mdio->prtad, MDIO_MMD_AN,
+ MDIO_CTRL1);
+   if (reg & MDIO_AN_CTRL1_ENABLE) {
+   cmd->base.autoneg = AUTONEG_ENABLE;
+   advertising |=
+   ADVERTISED_Autoneg |
+

[PATCH v2 2/2] net: sfc: falcon: use new api ethtool_{get|set}_link_ksettings

[Philippe Reynes]

The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.

Signed-off-by: Philippe Reynes 
---
Changelog:
v2:
- simplify the code of ef4_ethtool_get_link_ksettings
  (feedback from Bert Kenward)

 drivers/net/ethernet/sfc/falcon/efx.c  |2 +-
 drivers/net/ethernet/sfc/falcon/ethtool.c  |   29 +---
 drivers/net/ethernet/sfc/falcon/mdio_10g.c |   44 +++-
 drivers/net/ethernet/sfc/falcon/mdio_10g.h |3 +-
 drivers/net/ethernet/sfc/falcon/net_driver.h   |   12 +++---
 drivers/net/ethernet/sfc/falcon/qt202x_phy.c   |9 +++--
 drivers/net/ethernet/sfc/falcon/tenxpress.c|   22 ++--
 drivers/net/ethernet/sfc/falcon/txc43128_phy.c |9 +++--
 8 files changed, 74 insertions(+), 56 deletions(-)

diff --git a/drivers/net/ethernet/sfc/falcon/efx.c 
b/drivers/net/ethernet/sfc/falcon/efx.c
index 5c5cb3c..438ef9e 100644
--- a/drivers/net/ethernet/sfc/falcon/efx.c
+++ b/drivers/net/ethernet/sfc/falcon/efx.c
@@ -986,7 +986,7 @@ void ef4_mac_reconfigure(struct ef4_nic *efx)
 
 /* Push loopback/power/transmit disable settings to the PHY, and reconfigure
  * the MAC appropriately. All other PHY configuration changes are pushed
- * through phy_op->set_settings(), and pushed asynchronously to the MAC
+ * through phy_op->set_link_ksettings(), and pushed asynchronously to the MAC
  * through ef4_monitor().
  *
  * Callers must hold the mac_lock
diff --git a/drivers/net/ethernet/sfc/falcon/ethtool.c 
b/drivers/net/ethernet/sfc/falcon/ethtool.c
index 8e1929b..5604915 100644
--- a/drivers/net/ethernet/sfc/falcon/ethtool.c
+++ b/drivers/net/ethernet/sfc/falcon/ethtool.c
@@ -115,44 +115,47 @@ static int ef4_ethtool_phys_id(struct net_device *net_dev,
 }
 
 /* This must be called with rtnl_lock held. */
-static int ef4_ethtool_get_settings(struct net_device *net_dev,
-   struct ethtool_cmd *ecmd)
+static int
+ef4_ethtool_get_link_ksettings(struct net_device *net_dev,
+  struct ethtool_link_ksettings *cmd)
 {
struct ef4_nic *efx = netdev_priv(net_dev);
struct ef4_link_state *link_state = &efx->link_state;
 
mutex_lock(&efx->mac_lock);
-   efx->phy_op->get_settings(efx, ecmd);
+   efx->phy_op->get_link_ksettings(efx, cmd);
mutex_unlock(&efx->mac_lock);
 
/* Both MACs support pause frames (bidirectional and respond-only) */
-   ecmd->supported |= SUPPORTED_Pause | SUPPORTED_Asym_Pause;
+   ethtool_link_ksettings_add_link_mode(cmd, supported, Pause);
+   ethtool_link_ksettings_add_link_mode(cmd, supported, Asym_Pause);
 
if (LOOPBACK_INTERNAL(efx)) {
-   ethtool_cmd_speed_set(ecmd, link_state->speed);
-   ecmd->duplex = link_state->fd ? DUPLEX_FULL : DUPLEX_HALF;
+   cmd->base.speed = link_state->speed;
+   cmd->base.duplex = link_state->fd ? DUPLEX_FULL : DUPLEX_HALF;
}
 
return 0;
 }
 
 /* This must be called with rtnl_lock held. */
-static int ef4_ethtool_set_settings(struct net_device *net_dev,
-   struct ethtool_cmd *ecmd)
+static int
+ef4_ethtool_set_link_ksettings(struct net_device *net_dev,
+  const struct ethtool_link_ksettings *cmd)
 {
struct ef4_nic *efx = netdev_priv(net_dev);
int rc;
 
/* GMAC does not support 1000Mbps HD */
-   if ((ethtool_cmd_speed(ecmd) == SPEED_1000) &&
-   (ecmd->duplex != DUPLEX_FULL)) {
+   if ((cmd->base.speed == SPEED_1000) &&
+   (cmd->base.duplex != DUPLEX_FULL)) {
netif_dbg(efx, drv, efx->net_dev,
  "rejecting unsupported 1000Mbps HD setting\n");
return -EINVAL;
}
 
mutex_lock(&efx->mac_lock);
-   rc = efx->phy_op->set_settings(efx, ecmd);
+   rc = efx->phy_op->set_link_ksettings(efx, cmd);
mutex_unlock(&efx->mac_lock);
return rc;
 }
@@ -1310,8 +1313,6 @@ static int ef4_ethtool_get_module_info(struct net_device 
*net_dev,
 }
 
 const struct ethtool_ops ef4_ethtool_ops = {
-   .get_settings   = ef4_ethtool_get_settings,
-   .set_settings   = ef4_ethtool_set_settings,
.get_drvinfo= ef4_ethtool_get_drvinfo,
.get_regs_len   = ef4_ethtool_get_regs_len,
.get_regs   = ef4_ethtool_get_regs,
@@ -1340,4 +1341,6 @@ static int ef4_ethtool_get_module_info(struct net_device 
*net_dev,
.set_rxfh   = ef4_ethtool_set_rxfh,
.get_module_info= ef4_ethtool_get_module_info,
.get_module_eeprom  = ef4_ethtool_get_module_eeprom,
+   .get_link_ksettings = ef4_ethtool_get_link_ksettings,
+   .set_link_ksettings = ef4_ethtool_set_link_ksettings,
 };
diff --git a/drivers/net/ethernet/sfc/falcon/mdio_10g.c 
b/drivers/net/ethernet/sfc/falcon/mdio_10g.c
index e7d7c09..ee0713f 10

[PATCH] net: dec: de2104x: use new api ethtool_{get|set}_link_ksettings

[Philippe Reynes]

The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/dec/tulip/de2104x.c |   91 +-
 1 files changed, 51 insertions(+), 40 deletions(-)

diff --git a/drivers/net/ethernet/dec/tulip/de2104x.c 
b/drivers/net/ethernet/dec/tulip/de2104x.c
index 57c17e7..127ce970 100644
--- a/drivers/net/ethernet/dec/tulip/de2104x.c
+++ b/drivers/net/ethernet/dec/tulip/de2104x.c
@@ -1485,95 +1485,104 @@ static void __de_get_regs(struct de_private *de, u8 
*buf)
de_rx_missed(de, rbuf[8]);
 }
 
-static int __de_get_settings(struct de_private *de, struct ethtool_cmd *ecmd)
+static int __de_get_link_ksettings(struct de_private *de,
+  struct ethtool_link_ksettings *cmd)
 {
-   ecmd->supported = de->media_supported;
-   ecmd->transceiver = XCVR_INTERNAL;
-   ecmd->phy_address = 0;
-   ecmd->advertising = de->media_advertise;
+   ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.supported,
+   de->media_supported);
+   cmd->base.phy_address = 0;
+   ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.advertising,
+   de->media_advertise);
 
switch (de->media_type) {
case DE_MEDIA_AUI:
-   ecmd->port = PORT_AUI;
+   cmd->base.port = PORT_AUI;
break;
case DE_MEDIA_BNC:
-   ecmd->port = PORT_BNC;
+   cmd->base.port = PORT_BNC;
break;
default:
-   ecmd->port = PORT_TP;
+   cmd->base.port = PORT_TP;
break;
}
 
-   ethtool_cmd_speed_set(ecmd, 10);
+   cmd->base.speed = 10;
 
if (dr32(MacMode) & FullDuplex)
-   ecmd->duplex = DUPLEX_FULL;
+   cmd->base.duplex = DUPLEX_FULL;
else
-   ecmd->duplex = DUPLEX_HALF;
+   cmd->base.duplex = DUPLEX_HALF;
 
if (de->media_lock)
-   ecmd->autoneg = AUTONEG_DISABLE;
+   cmd->base.autoneg = AUTONEG_DISABLE;
else
-   ecmd->autoneg = AUTONEG_ENABLE;
+   cmd->base.autoneg = AUTONEG_ENABLE;
 
/* ignore maxtxpkt, maxrxpkt for now */
 
return 0;
 }
 
-static int __de_set_settings(struct de_private *de, struct ethtool_cmd *ecmd)
+static int __de_set_link_ksettings(struct de_private *de,
+  const struct ethtool_link_ksettings *cmd)
 {
u32 new_media;
unsigned int media_lock;
+   u8 duplex = cmd->base.duplex;
+   u8 port = cmd->base.port;
+   u8 autoneg = cmd->base.autoneg;
+   u32 advertising;
 
-   if (ethtool_cmd_speed(ecmd) != 10)
-   return -EINVAL;
-   if (ecmd->duplex != DUPLEX_HALF && ecmd->duplex != DUPLEX_FULL)
+   ethtool_convert_link_mode_to_legacy_u32(&advertising,
+   cmd->link_modes.advertising);
+
+   if (cmd->base.speed != 10)
return -EINVAL;
-   if (ecmd->port != PORT_TP && ecmd->port != PORT_AUI && ecmd->port != 
PORT_BNC)
+   if (duplex != DUPLEX_HALF && duplex != DUPLEX_FULL)
return -EINVAL;
-   if (de->de21040 && ecmd->port == PORT_BNC)
+   if (port != PORT_TP && port != PORT_AUI && port != PORT_BNC)
return -EINVAL;
-   if (ecmd->transceiver != XCVR_INTERNAL)
+   if (de->de21040 && port == PORT_BNC)
return -EINVAL;
-   if (ecmd->autoneg != AUTONEG_DISABLE && ecmd->autoneg != AUTONEG_ENABLE)
+   if (autoneg != AUTONEG_DISABLE && autoneg != AUTONEG_ENABLE)
return -EINVAL;
-   if (ecmd->advertising & ~de->media_supported)
+   if (advertising & ~de->media_supported)
return -EINVAL;
-   if (ecmd->autoneg == AUTONEG_ENABLE &&
-   (!(ecmd->advertising & ADVERTISED_Autoneg)))
+   if (autoneg == AUTONEG_ENABLE &&
+   (!(advertising & ADVERTISED_Autoneg)))
return -EINVAL;
 
-   switch (ecmd->port) {
+   switch (port) {
case PORT_AUI:
new_media = DE_MEDIA_AUI;
-   if (!(ecmd->advertising & ADVERTISED_AUI))
+   if (!(advertising & ADVERTISED_AUI))
return -EINVAL;
break;
case PORT_BNC:
new_media = DE_MEDIA_BNC;
-   if (!(ecmd->advertising & ADVERTISED_BNC))
+   if (!(advertising & ADVERTISED_BNC))
return -EINVAL;
break;
default:
-   if (ecmd->autoneg == AUTONEG_ENABLE)
+   if (autoneg == AUTONEG_ENABLE)
new_media = DE_MEDIA_TP_AUTO;
-   else if (ecmd->duplex == DUPLEX_FULL)
+   else if (duplex == DUPLEX_FULL)
n

[PATCH] net: dec: uli526x: use new api ethtool_{get|set}_link_ksettings

[Philippe Reynes]

The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/dec/tulip/uli526x.c |   41 +
 1 files changed, 24 insertions(+), 17 deletions(-)

diff --git a/drivers/net/ethernet/dec/tulip/uli526x.c 
b/drivers/net/ethernet/dec/tulip/uli526x.c
index f82ebe5..8d98b259 100644
--- a/drivers/net/ethernet/dec/tulip/uli526x.c
+++ b/drivers/net/ethernet/dec/tulip/uli526x.c
@@ -926,48 +926,53 @@ static void uli526x_set_filter_mode(struct net_device * 
dev)
 }
 
 static void
-ULi_ethtool_gset(struct uli526x_board_info *db, struct ethtool_cmd *ecmd)
+ULi_ethtool_get_link_ksettings(struct uli526x_board_info *db,
+  struct ethtool_link_ksettings *cmd)
 {
-   ecmd->supported = (SUPPORTED_10baseT_Half |
+   u32 supported, advertising;
+
+   supported = (SUPPORTED_10baseT_Half |
   SUPPORTED_10baseT_Full |
   SUPPORTED_100baseT_Half |
   SUPPORTED_100baseT_Full |
   SUPPORTED_Autoneg |
   SUPPORTED_MII);
 
-   ecmd->advertising = (ADVERTISED_10baseT_Half |
+   advertising = (ADVERTISED_10baseT_Half |
   ADVERTISED_10baseT_Full |
   ADVERTISED_100baseT_Half |
   ADVERTISED_100baseT_Full |
   ADVERTISED_Autoneg |
   ADVERTISED_MII);
 
+   ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.supported,
+   supported);
+   ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.advertising,
+   advertising);
 
-   ecmd->port = PORT_MII;
-   ecmd->phy_address = db->phy_addr;
-
-   ecmd->transceiver = XCVR_EXTERNAL;
+   cmd->base.port = PORT_MII;
+   cmd->base.phy_address = db->phy_addr;
 
-   ethtool_cmd_speed_set(ecmd, SPEED_10);
-   ecmd->duplex = DUPLEX_HALF;
+   cmd->base.speed = SPEED_10;
+   cmd->base.duplex = DUPLEX_HALF;
 
if(db->op_mode==ULI526X_100MHF || db->op_mode==ULI526X_100MFD)
{
-   ethtool_cmd_speed_set(ecmd, SPEED_100);
+   cmd->base.speed = SPEED_100;
}
if(db->op_mode==ULI526X_10MFD || db->op_mode==ULI526X_100MFD)
{
-   ecmd->duplex = DUPLEX_FULL;
+   cmd->base.duplex = DUPLEX_FULL;
}
if(db->link_failed)
{
-   ethtool_cmd_speed_set(ecmd, SPEED_UNKNOWN);
-   ecmd->duplex = DUPLEX_UNKNOWN;
+   cmd->base.speed = SPEED_UNKNOWN;
+   cmd->base.duplex = DUPLEX_UNKNOWN;
}
 
if (db->media_mode & ULI526X_AUTO)
{
-   ecmd->autoneg = AUTONEG_ENABLE;
+   cmd->base.autoneg = AUTONEG_ENABLE;
}
 }
 
@@ -981,10 +986,12 @@ static void netdev_get_drvinfo(struct net_device *dev,
strlcpy(info->bus_info, pci_name(np->pdev), sizeof(info->bus_info));
 }
 
-static int netdev_get_settings(struct net_device *dev, struct ethtool_cmd 
*cmd) {
+static int netdev_get_link_ksettings(struct net_device *dev,
+struct ethtool_link_ksettings *cmd)
+{
struct uli526x_board_info *np = netdev_priv(dev);
 
-   ULi_ethtool_gset(np, cmd);
+   ULi_ethtool_get_link_ksettings(np, cmd);
 
return 0;
 }
@@ -1006,9 +1013,9 @@ static void uli526x_get_wol(struct net_device *dev, 
struct ethtool_wolinfo *wol)
 
 static const struct ethtool_ops netdev_ethtool_ops = {
.get_drvinfo= netdev_get_drvinfo,
-   .get_settings   = netdev_get_settings,
.get_link   = netdev_get_link,
.get_wol= uli526x_get_wol,
+   .get_link_ksettings = netdev_get_link_ksettings,
 };
 
 /*
-- 
1.7.4.4

Re: wlcore: fix spelling mistake in wl1271_warning

[Kalle Valo]

Colin Ian King  wrote:
> From: Colin Ian King 
> 
> trivial fix to spelling mistake of function name in wl1271_warning,
> should be dynamic_ps_timeout instead of dyanmic_ps_timeout.
> 
> Signed-off-by: Colin Ian King 

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

a60db8e70313 wlcore: fix spelling mistake in wl1271_warning

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

Documentation about submitting wireless patches and checking status
from patchwork:

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

Re: [V3] rtlwifi: fix spelling mistake: "encrypiton" -> "encryption"

[Kalle Valo]

Colin Ian King  wrote:
> From: Colin Ian King 
> 
> trivial fix to spelling mistake in RT_TRACE message
> 
> Signed-off-by: Colin Ian King 

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

e16e558e83ed rtlwifi: fix spelling mistake: "encrypiton" -> "encryption"

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

Documentation about submitting wireless patches and checking status
from patchwork:

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

collect2: error: ld returned 1 exit status

[kbuild test robot]

Hi Linus,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   238d1d0f79f619d75c2cc741d6770fb0986aef24
commit: 2527ecc9195e9c66252af24c4689e8a67cd4ccb9 gpio: Fix OF build problem on 
UM
date:   5 months ago
config: um-allyesconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 2527ecc9195e9c66252af24c4689e8a67cd4ccb9
# save the attached .config to linux build tree
make ARCH=um 

All errors (new ones prefixed by >>):

   arch/um/drivers/built-in.o: In function `vde_open_real':
   (.text+0xc7d1): warning: Using 'getgrnam' in statically linked applications 
requires at runtime the shared libraries from the glibc version used for linking
   arch/um/drivers/built-in.o: In function `vde_open_real':
   (.text+0xc61c): warning: Using 'getpwuid' in statically linked applications 
requires at runtime the shared libraries from the glibc version used for linking
   arch/um/drivers/built-in.o: In function `vde_open_real':
   (.text+0xc935): warning: Using 'getaddrinfo' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametoaddr':
   (.text+0x1d3c5): warning: Using 'gethostbyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametonetaddr':
   (.text+0x1d465): warning: Using 'getnetbyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametoproto':
   (.text+0x1d685): warning: Using 'getprotobyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametoport':
   (.text+0x1d4b7): warning: Using 'getservbyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   drivers/built-in.o: In function `fwnode_get_named_gpiod':
   drivers/gpio/gpiolib.c:3215: undefined reference to 
`of_get_named_gpiod_flags'
   drivers/built-in.o: In function `gpiod_get_index':
   drivers/gpio/gpiolib.c:3140: undefined reference to 
`of_get_named_gpiod_flags'
   drivers/built-in.o: In function `lp872x_probe':
   drivers/regulator/lp872x.c:773: undefined reference to 
`devm_gpio_request_one'
   drivers/regulator/lp872x.c:746: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `max8952_pmic_probe':
   drivers/regulator/max8952.c:249: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `max8973_probe':
   drivers/regulator/max8973-regulator.c:715: undefined reference to 
`devm_gpio_request_one'
   drivers/regulator/max8973-regulator.c:770: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `pwm_regulator_probe':
   drivers/regulator/pwm-regulator.c:387: undefined reference to 
`devm_gpiod_get_optional'
   drivers/built-in.o: In function `tps62360_probe':
   drivers/regulator/tps62360-regulator.c:433: undefined reference to 
`devm_gpio_request_one'
   drivers/regulator/tps62360-regulator.c:444: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `fdp_nci_i2c_probe':
   drivers/nfc/fdp/i2c.c:326: undefined reference to `devm_gpiod_get'
   drivers/built-in.o: In function `nfcmrvl_nci_unregister_dev':
   drivers/nfc/nfcmrvl/main.c:198: undefined reference to `devm_gpio_free'
   drivers/built-in.o: In function `nfcmrvl_nci_register_dev':
   drivers/nfc/nfcmrvl/main.c:127: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `st21nfca_hci_i2c_probe':
   drivers/nfc/st21nfca/i2c.c:597: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `st_nci_i2c_probe':
   drivers/nfc/st-nci/i2c.c:300: undefined reference to `devm_gpio_request_one'
   drivers/built-in.o: In function `nxp_nci_i2c_probe':
   drivers/nfc/nxp-nci/i2c.c:361: undefined reference to `devm_gpio_request_one'
   drivers/built-in.o: In function `mdio_gpio_probe':
   drivers/net/phy/mdio-gpio.c:177: undefined reference to `devm_gpio_request'
   drivers/built-in.o: In function `at803x_probe':
   drivers/net/phy/at803x.c:283: undefined reference to 
`devm_gpiod_get_optional'
   drivers/built-in.o: In function `mv88e6xxx_probe':
   drivers/net/dsa/mv88e6xxx/chip.c:4022: undefined reference to 
`devm_gpiod_get_optional'
   drivers/built-in.o: In function `pps_gpio_probe':
   drivers/pps/clients/pps-gpio.c:125: undefined reference to 
`devm_gpio_request'
   drivers/built-in.o: In function `max8903_probe':
   drivers/power/max8903_charger.c:248: undefined reference to 
`devm_gpio_request'
   drivers/power/max8903_charger.c:280: undefined re

[PATCH] net: dec: winbond-840: use new api ethtool_{get|set}_link_ksettings

[Philippe Reynes]

The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/dec/tulip/winbond-840.c |   14 --
 1 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/dec/tulip/winbond-840.c 
b/drivers/net/ethernet/dec/tulip/winbond-840.c
index bc9bf88..d1f2f3c 100644
--- a/drivers/net/ethernet/dec/tulip/winbond-840.c
+++ b/drivers/net/ethernet/dec/tulip/winbond-840.c
@@ -1391,25 +1391,27 @@ static void netdev_get_drvinfo (struct net_device *dev, 
struct ethtool_drvinfo *
strlcpy(info->bus_info, pci_name(np->pci_dev), sizeof(info->bus_info));
 }
 
-static int netdev_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
+static int netdev_get_link_ksettings(struct net_device *dev,
+struct ethtool_link_ksettings *cmd)
 {
struct netdev_private *np = netdev_priv(dev);
int rc;
 
spin_lock_irq(&np->lock);
-   rc = mii_ethtool_gset(&np->mii_if, cmd);
+   rc = mii_ethtool_get_link_ksettings(&np->mii_if, cmd);
spin_unlock_irq(&np->lock);
 
return rc;
 }
 
-static int netdev_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
+static int netdev_set_link_ksettings(struct net_device *dev,
+const struct ethtool_link_ksettings *cmd)
 {
struct netdev_private *np = netdev_priv(dev);
int rc;
 
spin_lock_irq(&np->lock);
-   rc = mii_ethtool_sset(&np->mii_if, cmd);
+   rc = mii_ethtool_set_link_ksettings(&np->mii_if, cmd);
spin_unlock_irq(&np->lock);
 
return rc;
@@ -1439,12 +1441,12 @@ static void netdev_set_msglevel(struct net_device *dev, 
u32 value)
 
 static const struct ethtool_ops netdev_ethtool_ops = {
.get_drvinfo= netdev_get_drvinfo,
-   .get_settings   = netdev_get_settings,
-   .set_settings   = netdev_set_settings,
.nway_reset = netdev_nway_reset,
.get_link   = netdev_get_link,
.get_msglevel   = netdev_get_msglevel,
.set_msglevel   = netdev_set_msglevel,
+   .get_link_ksettings = netdev_get_link_ksettings,
+   .set_link_ksettings = netdev_set_link_ksettings,
 };
 
 static int netdev_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
-- 
1.7.4.4

[PATCH] net: dlink: dl2k: use new api ethtool_{get|set}_link_ksettings

[Philippe Reynes]

The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.

The previous implementation of set_settings was modifying
the value of speed and duplex, but with the new API, it's not
possible. The structure ethtool_link_ksettings is defined
as const.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/dlink/dl2k.c |   71 +---
 1 files changed, 41 insertions(+), 30 deletions(-)

diff --git a/drivers/net/ethernet/dlink/dl2k.c 
b/drivers/net/ethernet/dlink/dl2k.c
index 8c95a8a..1e35013 100644
--- a/drivers/net/ethernet/dlink/dl2k.c
+++ b/drivers/net/ethernet/dlink/dl2k.c
@@ -1256,52 +1256,63 @@ static void rio_get_drvinfo(struct net_device *dev, 
struct ethtool_drvinfo *info
strlcpy(info->bus_info, pci_name(np->pdev), sizeof(info->bus_info));
 }
 
-static int rio_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
+static int rio_get_link_ksettings(struct net_device *dev,
+ struct ethtool_link_ksettings *cmd)
 {
struct netdev_private *np = netdev_priv(dev);
+   u32 supported, advertising;
+
if (np->phy_media) {
/* fiber device */
-   cmd->supported = SUPPORTED_Autoneg | SUPPORTED_FIBRE;
-   cmd->advertising= ADVERTISED_Autoneg | ADVERTISED_FIBRE;
-   cmd->port = PORT_FIBRE;
-   cmd->transceiver = XCVR_INTERNAL;
+   supported = SUPPORTED_Autoneg | SUPPORTED_FIBRE;
+   advertising = ADVERTISED_Autoneg | ADVERTISED_FIBRE;
+   cmd->base.port = PORT_FIBRE;
} else {
/* copper device */
-   cmd->supported = SUPPORTED_10baseT_Half |
+   supported = SUPPORTED_10baseT_Half |
SUPPORTED_10baseT_Full | SUPPORTED_100baseT_Half
| SUPPORTED_100baseT_Full | SUPPORTED_1000baseT_Full |
SUPPORTED_Autoneg | SUPPORTED_MII;
-   cmd->advertising = ADVERTISED_10baseT_Half |
+   advertising = ADVERTISED_10baseT_Half |
ADVERTISED_10baseT_Full | ADVERTISED_100baseT_Half |
-   ADVERTISED_100baseT_Full | ADVERTISED_1000baseT_Full|
+   ADVERTISED_100baseT_Full | ADVERTISED_1000baseT_Full |
ADVERTISED_Autoneg | ADVERTISED_MII;
-   cmd->port = PORT_MII;
-   cmd->transceiver = XCVR_INTERNAL;
+   cmd->base.port = PORT_MII;
}
-   if ( np->link_status ) {
-   ethtool_cmd_speed_set(cmd, np->speed);
-   cmd->duplex = np->full_duplex ? DUPLEX_FULL : DUPLEX_HALF;
+   if (np->link_status) {
+   cmd->base.speed = np->speed;
+   cmd->base.duplex = np->full_duplex ? DUPLEX_FULL : DUPLEX_HALF;
} else {
-   ethtool_cmd_speed_set(cmd, SPEED_UNKNOWN);
-   cmd->duplex = DUPLEX_UNKNOWN;
+   cmd->base.speed = SPEED_UNKNOWN;
+   cmd->base.duplex = DUPLEX_UNKNOWN;
}
-   if ( np->an_enable)
-   cmd->autoneg = AUTONEG_ENABLE;
+   if (np->an_enable)
+   cmd->base.autoneg = AUTONEG_ENABLE;
else
-   cmd->autoneg = AUTONEG_DISABLE;
+   cmd->base.autoneg = AUTONEG_DISABLE;
+
+   cmd->base.phy_address = np->phy_addr;
+
+   ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.supported,
+   supported);
+   ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.advertising,
+   advertising);
 
-   cmd->phy_address = np->phy_addr;
return 0;
 }
 
-static int rio_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
+static int rio_set_link_ksettings(struct net_device *dev,
+ const struct ethtool_link_ksettings *cmd)
 {
struct netdev_private *np = netdev_priv(dev);
+   u32 speed = cmd->base.speed;
+   u8 duplex = cmd->base.duplex;
+
netif_carrier_off(dev);
-   if (cmd->autoneg == AUTONEG_ENABLE) {
-   if (np->an_enable)
+   if (cmd->base.autoneg == AUTONEG_ENABLE) {
+   if (np->an_enable) {
return 0;
-   else {
+   } else {
np->an_enable = 1;
mii_set_media(dev);
return 0;
@@ -1309,18 +1320,18 @@ static int rio_set_settings(struct net_device *dev, 
struct ethtool_cmd *cmd)
} else {
np->an_enable = 0;
if (np->speed == 1000) {
-   ethtool_cmd_speed_set(cmd, SPEED_100);
-   cmd->duplex = DUPLEX_FULL;
+   speed = SPEED_100;
+   duplex = DUPLEX_FULL;
printk("Warning!! Can't disable Auto negotiation in 
1000Mbps, c

[PATCH] net: dlink: sundance: use new api ethtool_{get|set}_link_ksettings

[Philippe Reynes]

The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/dlink/sundance.c |   14 --
 1 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/dlink/sundance.c 
b/drivers/net/ethernet/dlink/sundance.c
index 2e5b667..2704bcf 100644
--- a/drivers/net/ethernet/dlink/sundance.c
+++ b/drivers/net/ethernet/dlink/sundance.c
@@ -1664,21 +1664,23 @@ static void get_drvinfo(struct net_device *dev, struct 
ethtool_drvinfo *info)
strlcpy(info->bus_info, pci_name(np->pci_dev), sizeof(info->bus_info));
 }
 
-static int get_settings(struct net_device *dev, struct ethtool_cmd *ecmd)
+static int get_link_ksettings(struct net_device *dev,
+ struct ethtool_link_ksettings *cmd)
 {
struct netdev_private *np = netdev_priv(dev);
spin_lock_irq(&np->lock);
-   mii_ethtool_gset(&np->mii_if, ecmd);
+   mii_ethtool_get_link_ksettings(&np->mii_if, cmd);
spin_unlock_irq(&np->lock);
return 0;
 }
 
-static int set_settings(struct net_device *dev, struct ethtool_cmd *ecmd)
+static int set_link_ksettings(struct net_device *dev,
+ const struct ethtool_link_ksettings *cmd)
 {
struct netdev_private *np = netdev_priv(dev);
int res;
spin_lock_irq(&np->lock);
-   res = mii_ethtool_sset(&np->mii_if, ecmd);
+   res = mii_ethtool_set_link_ksettings(&np->mii_if, cmd);
spin_unlock_irq(&np->lock);
return res;
 }
@@ -1800,8 +1802,6 @@ static int sundance_set_wol(struct net_device *dev,
 static const struct ethtool_ops ethtool_ops = {
.begin = check_if_running,
.get_drvinfo = get_drvinfo,
-   .get_settings = get_settings,
-   .set_settings = set_settings,
.nway_reset = nway_reset,
.get_link = get_link,
.get_wol = sundance_get_wol,
@@ -1811,6 +1811,8 @@ static int sundance_set_wol(struct net_device *dev,
.get_strings = get_strings,
.get_sset_count = get_sset_count,
.get_ethtool_stats = get_ethtool_stats,
+   .get_link_ksettings = get_link_ksettings,
+   .set_link_ksettings = set_link_ksettings,
 };
 
 static int netdev_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
-- 
1.7.4.4

Nokia N900 sound driver and ECI GPIOs

[Pali Rohár]

Hi!

I'm looking at original Maemo N900 2.6.28 sound driver and GPIOs which
controls A/V jack detection.

For reference source code of that driver can be found e.g. at alsa-devel
ML [1] [2] or in my linux-n900 git tree, branch v2.6.28-nokia [3].

In that sound/soc/omap/rx51.c code is function rx51_set_eci_switches()
which configures 2 gpios: RX51_ECI_SWITCH_1_GPIO = gpio 178 and
RX51_ECI_SWITCH_2_GPIO = gpio 182 based on "eci mode" input parameter.

But in mainline kernel code [4] [5] there is no information about gpio 178
(as RX51_ECI_SWITCH_1_GPIO) and gpio 182 is called as just "eci-switch".
More interesting part is that "eci-switch" gpio is not used in whole
mainline code. It is just referenced in Nokia N900 DTS [4]. Looks like
sound driver in mainline kernel is incomplete.

Jarkko, you are listed as original author of that driver. Do you (or
anybody else) remember what that rx51_set_eci_switches() function is
doing? And what gpio 178 controls? I was even not able to find gpio 178
in RX-51 Schematics [6].

And do you know something about Nokia ECI headsets supports for Nokia
N900. Looks like there is already some kernel code but support for ECI
bus or multibuttons headset is missing.

[1] - 
http://mailman.alsa-project.org/pipermail/alsa-devel/2009-October/022033.html

[2] - 
http://mailman.alsa-project.org/pipermail/alsa-devel/2009-October/022039.html

[3] - 
https://github.com/pali/linux-n900/blob/v2.6.28-nokia/sound/soc/omap/rx51.c

[4] - 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap3-n900.dts#n128

[5] - 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/sound/soc/omap/rx51.c

[6] - https://wiki.maemo.org/N900_Hardware_Schematic

-- 
Pali Rohár
pali.ro...@gmail.com


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

[PATCH V7 0/4] Add driver for GE B850v3 LVDS/DP++ Bridge

[Peter Senna Tschudin]

The series adds a driver that creates a drm_bridge and a drm_connector for the
LVDS to DP++ display bridge of the GE B850v3.

There are two physical bridges on the video signal pipeline: a STDP4028(LVDS to
DP) and a STDP2690(DP to DP++).  The hardware and firmware made it complicated
for this binding to comprise two device tree nodes, as the design goal is to
configure both bridges based on the LVDS signal, which leave the driver
powerless to control the video processing pipeline. The two bridges behaves as
a single bridge, and the driver is only needed for telling the host about EDID /
HPD, and for giving the host powers to ack interrupts. The video signal
pipeline is as follows:

  Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output

This series depends on commit dc80d7038883 ("drm/imx-ldb: Add support to
drm-bridge") which is already on linux-next.

The patches from the series:
 [1/4] Devicetree documentation for the GE B850v3 LVDS/DP++ Bridge

 [2/4] Update the MAINTAINERS file

 [3/4] Add the driver, make changes to Kconfig and Makefile

 [4/4] Make the changes to the B850v3 dts file to enable the GE B850v3
   LVDS/DP++ Bridge.

Tested on next20161224.

Changes from V6:
 - Removed check for pixel clock as the bridge supports up to 330Mhz while the
   host is limited to 264 MHz in very specific conditions.
 - Added a second mutex to avoid concurrency issues while acking interrupts
   from threaded interrupt handlers.
 - Renamed the edid mutex to be more descriptive.
 - Added a .detach() function that disables the interrupts.
 - Adopted i2c_new_secondary_device() and updated the dts and documentation to
   match the new method.
 - Removed useless test to drm_bridge_add()
 - Did some refactoring around devm_request_threaded_irq()
 - Added a missing call to i2c_unregister_device() on the i2c_driver.remove()
   function.

Changes from V5:
 - Change to MAINTAINERS in a separate patch
 - Reworked interrupt handler initialization
 - Removed useless calls to: drm_connector_register(),
   drm_helper_hpd_irq_event(), and drm_bridge_enable()

Changes from V4:
 - Renamed the i2c_driver.name from "ge,b850v3-lvds-dp" to "b850v3-lvds-dp" to
   remove the comma from the driver name

Changes from V3:
 - Removed the patch that was configuring the mapping between IPUs and external
   displays on the dts file

Peter Senna Tschudin (4):
  Documentation/devicetree/bindings: b850v3_lvds_dp
  MAINTAINERS: Add entry for GE B850v3 LVDS/DP++ Bridge
  drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge
  dts/imx6q-b850v3: Use GE B850v3 LVDS/DP++ Bridge

 .../devicetree/bindings/ge/b850v3-lvds-dp.txt  |  39 +++
 MAINTAINERS|   8 +
 arch/arm/boot/dts/imx6q-b850v3.dts |  30 ++
 drivers/gpu/drm/bridge/Kconfig |  11 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c | 384 +
 6 files changed, 473 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
 create mode 100644 drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c

-- 
2.5.5

[PATCH V7 1/4] Documentation/devicetree/bindings: b850v3_lvds_dp

[Peter Senna Tschudin]

Devicetree bindings documentation for the GE B850v3 LVDS/DP++
display bridge.

Cc: Martyn Welch 
Cc: Martin Donnelly 
Cc: Javier Martinez Canillas 
Cc: Enric Balletbo i Serra 
Cc: Philipp Zabel 
Cc: Rob Herring 
Cc: Fabio Estevam 
Signed-off-by: Peter Senna Tschudin 
---
There was an Acked-by from Rob Herring  for V6, but I changed
the bindings to use i2c_new_secondary_device() so I removed it from the commit
message.

 .../devicetree/bindings/ge/b850v3-lvds-dp.txt  | 39 ++
 1 file changed, 39 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt

diff --git a/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt 
b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
new file mode 100644
index 000..1bc6ebf
--- /dev/null
+++ b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
@@ -0,0 +1,39 @@
+Driver for GE B850v3 LVDS/DP++ display bridge
+
+Required properties:
+  - compatible : should be "ge,b850v3-lvds-dp".
+  - reg : should contain the main address which is used to ack the
+interrupts and address for edid.
+  - reg-names : comma separeted list of register names. Valid values
+are "main", and "edid".
+  - interrupt-parent : phandle of the interrupt controller that services
+interrupts to the device
+  - interrupts : one interrupt should be described here, as in
+<0 IRQ_TYPE_LEVEL_HIGH>.
+  - port : should describe the video signal connection between the host
+and the bridge.
+
+Example:
+
+&mux2_i2c2 {
+   status = "okay";
+   clock-frequency = <10>;
+
+   b850v3-lvds-dp-bridge@73  {
+   compatible = "ge,b850v3-lvds-dp";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   reg = <0x73 0x72>;
+   reg-names = "main", "edid";
+
+   interrupt-parent = <&gpio2>;
+   interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
+
+   port {
+   b850v3_dp_bridge_in: endpoint {
+   remote-endpoint = <&lvds0_out>;
+   };
+   };
+   };
+};
-- 
2.5.5

[PATCH V7 4/4] dts/imx6q-b850v3: Use GE B850v3 LVDS/DP++ Bridge

[Peter Senna Tschudin]

Configures the GE B850v3 LVDS/DP++ bridge on the dts file.

Cc: Martyn Welch 
Cc: Martin Donnelly 
Cc: Javier Martinez Canillas 
Cc: Enric Balletbo i Serra 
Cc: Philipp Zabel 
Cc: Rob Herring 
Cc: Fabio Estevam 
Signed-off-by: Peter Senna Tschudin 
---
 arch/arm/boot/dts/imx6q-b850v3.dts | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/imx6q-b850v3.dts 
b/arch/arm/boot/dts/imx6q-b850v3.dts
index 167f744..ce0ca3a 100644
--- a/arch/arm/boot/dts/imx6q-b850v3.dts
+++ b/arch/arm/boot/dts/imx6q-b850v3.dts
@@ -72,6 +72,13 @@
fsl,data-mapping = "spwg";
fsl,data-width = <24>;
status = "okay";
+
+   port@4 {
+   reg = <4>;
+   lvds0_out: endpoint {
+   remote-endpoint = <&b850v3_lvds_dp_bridge_in>;
+   };
+   };
};
 };
 
@@ -142,3 +149,26 @@
reg = <0x4a>;
};
 };
+
+&mux2_i2c2 {
+   status = "okay";
+   clock-frequency = <10>;
+
+   b850v3-lvds-dp-bridge@73 {
+   compatible = "ge,b850v3-lvds-dp";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   reg = <0x73 0x72>;
+   reg-names = "main", "edid";
+
+   interrupt-parent = <&gpio2>;
+   interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
+
+   port {
+   b850v3_lvds_dp_bridge_in: endpoint {
+   remote-endpoint = <&lvds0_out>;
+   };
+   };
+   };
+};
-- 
2.5.5

[PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge

[Peter Senna Tschudin]

Add a driver that create a drm_bridge and a drm_connector for the LVDS
to DP++ display bridge of the GE B850v3.

There are two physical bridges on the video signal pipeline: a
STDP4028(LVDS to DP) and a STDP2690(DP to DP++).  The hardware and
firmware made it complicated for this binding to comprise two device
tree nodes, as the design goal is to configure both bridges based on
the LVDS signal, which leave the driver powerless to control the video
processing pipeline. The two bridges behaves as a single bridge, and
the driver is only needed for telling the host about EDID / HPD, and
for giving the host powers to ack interrupts. The video signal pipeline
is as follows:

  Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output

Cc: Martyn Welch 
Cc: Martin Donnelly 
Cc: Daniel Vetter 
Cc: Enric Balletbo i Serra 
Cc: Philipp Zabel 
Cc: Rob Herring 
Cc: Fabio Estevam 
CC: David Airlie 
CC: Thierry Reding 
CC: Thierry Reding 
CC: Archit Taneja 
Reviewed-by: Enric Balletbo 
Signed-off-by: Peter Senna Tschudin 
---
 drivers/gpu/drm/bridge/Kconfig |  11 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c | 384 +
 3 files changed, 396 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index eb8688e..e3e1f3b 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -48,6 +48,17 @@ config DRM_DW_HDMI_I2S_AUDIO
  Support the I2S Audio interface which is part of the Synopsis
  Designware HDMI block.
 
+config DRM_GE_B850V3_LVDS_DP
+   tristate "GE B850v3 LVDS to DP++ display bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   select DRM_PANEL
+   ---help---
+  This is a driver for the display bridge of
+  GE B850v3 that convert dual channel LVDS
+  to DP++. This is used with the i.MX6 imx-ldb
+  driver.
+
 config DRM_NXP_PTN3460
tristate "NXP PTN3460 DP/LVDS bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 2e83a785..886d0fd 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
 obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o
+obj-$(CONFIG_DRM_GE_B850V3_LVDS_DP) += ge_b850v3_lvds_dp.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
diff --git a/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c 
b/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c
new file mode 100644
index 000..4574f6e
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c
@@ -0,0 +1,384 @@
+/*
+ * Driver for GE B850v3 DP display bridge
+
+ * Copyright (c) 2016, Collabora Ltd.
+ * Copyright (c) 2016, General Electric Company
+
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+
+ * This driver creates a drm_bridge and a drm_connector for the LVDS to DP++
+ * display bridge of the GE B850v3. There are two physical bridges on the video
+ * signal pipeline: a STDP4028(LVDS to DP) and a STDP2690(DP to DP++). However
+ * the physical bridges are automatically configured by the input video signal,
+ * and the driver has no access to the video processing pipeline. The driver is
+ * only needed to read EDID from the STDP2690 and to handle HPD events from the
+ * STDP4028. The driver communicates with both bridges over i2c. The video
+ * signal pipeline is as follows:
+ *
+ *   Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEFAULT_EDID_REG 0x72
+#define DEFAULT_EDID_REG_NAME "edid"
+
+#define EDID_EXT_BLOCK_CNT 0x7E
+
+#define STDP4028_IRQ_OUT_CONF_REG 0x02
+#define STDP4028_DPTX_IRQ_EN_REG 0x3C
+#define STDP4028_DPTX_IRQ_STS_REG 0x3D
+#define STDP4028_DPTX_STS_REG 0x3E
+
+#define STDP4028_DPTX_DP_IRQ_EN 0x1000
+
+#define STDP4028_DPTX_HOTPLUG_IRQ_EN 0x0400
+#define STDP4028_DPTX_LINK_CH_IRQ_EN 0x2000
+#define STDP4028_DPTX_IRQ_CONFIG \
+   (STDP4028_DPTX_LINK_CH_IRQ_EN | STDP4028_DPTX_HOTPLUG_IRQ

[PATCH V7 2/4] MAINTAINERS: Add entry for GE B850v3 LVDS/DP++ Bridge

[Peter Senna Tschudin]

Update the MAINTAINERS file for the GE B850v3 LVDS/DP++ Bridge.

Cc: Martyn Welch 
Cc: Martin Donnelly 
Cc: Daniel Vetter 
Cc: Enric Balletbo i Serra 
Cc: Philipp Zabel 
Cc: Rob Herring 
Cc: Fabio Estevam 
CC: David Airlie 
CC: Thierry Reding 
CC: Thierry Reding 
CC: Archit Taneja 
Signed-off-by: Peter Senna Tschudin 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index fdd9d5e3..1d3f17a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5371,6 +5371,14 @@ W:   https://linuxtv.org
 S: Maintained
 F: drivers/media/radio/radio-gemtek*
 
+GENERAL ELECTRIC B850V3 LVDS/DP++ BRIDGE
+M: Peter Senna Tschudin 
+M: Martin Donnelly 
+M: Martyn Welch 
+S: Maintained
+F: drivers/gpu/drm/bridge/ge_b850v3_dp2.c
+F: Documentation/devicetree/bindings/ge/b850v3_dp2_bridge.txt
+
 GENERIC GPIO I2C DRIVER
 M: Haavard Skinnemoen 
 S: Supported
-- 
2.5.5

nouveau_drm.c:undefined reference to `nouveau_led_suspend'

[kbuild test robot]

Hi Martin,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   238d1d0f79f619d75c2cc741d6770fb0986aef24
commit: 8d021d71b3247937a26ffdf313fd53a9d58778b7 drm/nouveau/drm/nouveau: add a 
LED driver for the NVIDIA logo
date:   3 months ago
config: x86_64-randconfig-h0-01020256 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout 8d021d71b3247937a26ffdf313fd53a9d58778b7
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `nouveau_do_suspend':
>> nouveau_drm.c:(.text+0x1fcb11): undefined reference to `nouveau_led_suspend'
   drivers/built-in.o: In function `nouveau_do_resume':
>> nouveau_drm.c:(.text+0x1fcf3a): undefined reference to `nouveau_led_resume'
   drivers/built-in.o: In function `nouveau_drm_unload':
>> nouveau_drm.c:(.text+0x1fd435): undefined reference to `nouveau_led_fini'
   drivers/built-in.o: In function `nouveau_drm_load':
>> nouveau_drm.c:(.text+0x1fde1b): undefined reference to `nouveau_led_init'

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


.config.gz
Description: application/gzip

Re: [PATCH] perf/core: introduce context per CPU event list

[David Carrillo-Cisneros]

On Sun, Jan 1, 2017 at 12:20 PM, David Carrillo-Cisneros
 wrote:
> From: Mark Rutland 
>
> On Thu, Nov 10, 2016 at 05:26:32PM +0100, Peter Zijlstra wrote:
>> On Thu, Nov 10, 2016 at 02:10:37PM +, Mark Rutland wrote:
>>
>> > Sure, that sounds fine for scheduling (including big.LITTLE).
>> >
>> > I might still be misunderstanding something, but I don't think that
>> > helps Kan's case: since INACTIVE events which will fail their filters
>> > (including the CPU check) will still be in the tree, they will still
>> > have to be iterated over.
>> >
>> > That is, unless we also sort the tree by event->cpu, or if in those
>> > cases we only care about ACTIVE events and can use an active list.
>>
>> A few emails back up I wrote:
>>
>> >> If we stick all events in an RB-tree sorted on: {pmu,cpu,runtime} we
>
> Ah, sorry. Clearly I wouldn't pass a reading comprehension test today.
>
>> Looking at the code there's also cgroup muck, not entirely sure where in
>> the sort order that should go if at all.
>>
>> But having pmu and cpu in there would cure the big-little and
>> per-task-per-cpu event issues.
>
> Yup, that all makes sense to me now (modulo the cgroup stuff I also
> haven't considered yet).

cgroup events are stored in each pmu's cpuctx, so they wouldn't benefit
from a pmu,cpu sort order. Yet the RB-tree would help if it could use cgroup
as key for cpu contexts.

Is there a reason to have runtime as part of the RB-tree?
Couldn't a FIFO list work just fine? A node could have an ACTIVE and
an INACTIVE FIFO list and just move the events in out the tree in ioctl and
to/from ACTIVE from/to INACTIVE on sched in/out.
This would speed up both sched in and sched out.

The node would be something like this:

struct ctx_rbnode {
struct rb_node node;
struct list_head active_events;
struct list_head inactive_events;
};

And the insertion order would be {pmu, cpu} for task contexts (cpu == -1
for events without fixed cpu) and {cgroup} for cpuctxs (CPU events would
have NULL cgrp).

Am I interested on getting this to work as part of the cgroup context switch
optimization that CQM/CMT needs. See discussion in:

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

Is anyone actively working on it?


Thanks,
David

Warning: You tried to send an email with blocked content

[Service Desk]

The UCL E-Mail Virus Protection System has been triggered by a message you sent.

One or more of the original e-mail attachments have been removed and replaced 
with this message.

* The attachment may have contained a virus or malware
* The attachment may have an extension of a type unacceptable for UCL

Consider renaming the file extension (eg rename file.ext to file.ex_)
to avoid this constraint.  The recipient will be required to rename the
file back to its original extension.

--
UCL E-mail Virus Protection System
serviced...@ucl.ac.uk
Phone: +44 (0)20 767925000 
Internal phone: 25000

--- Additional Information ---:

Subject: 
Sender: linux-kernel@vger.kernel.org

Time received: 1/1/2017 5:50:21 PM
Message ID:<148329299360.8866.15516723444560532...@skyonline.net.ar>
Detections found: 
31435906591.zip  O97M/Donoff.DN

Re: [PATCH v2] fscrypt: Factor out bio specific functions

[Theodore Ts'o]

On Mon, Dec 19, 2016 at 12:25:32PM +0100, Richard Weinberger wrote:
> That way we can get rid of the direct dependency on CONFIG_BLOCK.
> 
> Reported-by: Arnd Bergmann 
> Reported-by: Randy Dunlap 
> Suggested-by: Christoph Hellwig 
> Fixes: d475a507457b ("ubifs: Add skeleton for fscrypto")
> Signed-off-by: Richard Weinberger 

Applied, thanks.

- Ted

Re: [PATCH] mm: cma: print allocation failure reason and bitmap status

[Michal Nazarewicz]

On Fri, Dec 30 2016, Michal Hocko wrote:
> On Fri 30-12-16 16:24:46, Jaewon Kim wrote:
> [...]
>> >From 7577cc94da3af27907aa6eec590d2ef51e4b9d80 Mon Sep 17 00:00:00 2001
>> From: Jaewon Kim 
>> Date: Thu, 29 Dec 2016 11:00:16 +0900
>> Subject: [PATCH] mm: cma: print allocation failure reason and bitmap status
>> 
>> There are many reasons of CMA allocation failure such as EBUSY, ENOMEM, 
>> EINTR.
>> But we did not know error reason so far. This patch prints the error value.
>> 
>> Additionally if CONFIG_CMA_DEBUG is enabled, this patch shows bitmap status 
>> to
>> know available pages. Actually CMA internally try all available regions 
>> because
>> some regions can be failed because of EBUSY. Bitmap status is useful to know 
>> in
>> detail on both ENONEM and EBUSY;
>>  ENOMEM: not tried at all because of no available region
>>  it could be too small total region or could be fragmentation issue
>>  EBUSY:  tried some region but all failed
>> 
>> This is an ENOMEM example with this patch.
>> [   13.250961]  [1:   Binder:715_1:  846] cma: cma_alloc: alloc failed, 
>> req-size: 256 pages, ret: -12
>> Avabile pages also will be shown if CONFIG_CMA_DEBUG is enabled
>> [   13.251052]  [1:   Binder:715_1:  846] cma: number of available pages: 
>> 4@572+7@585+7@601+8@632+38@730+166@1114+127@1921=>357 pages, total: 2048 
>> pages
>
> please mention how to interpret this information.
>
> some more style suggestions below
>> 
>> Signed-off-by: Jaewon Kim 

Acked-by: Michal Nazarewicz 

>> ---
>>  mm/cma.c | 29 -
>>  1 file changed, 28 insertions(+), 1 deletion(-)
>> 
>> diff --git a/mm/cma.c b/mm/cma.c
>> index c960459..1bcd9db 100644
>> --- a/mm/cma.c
>> +++ b/mm/cma.c
>> @@ -369,7 +369,7 @@ struct page *cma_alloc(struct cma *cma, size_t count, 
>> unsigned int align)
>>  unsigned long start = 0;
>>  unsigned long bitmap_maxno, bitmap_no, bitmap_count;
>>  struct page *page = NULL;
>> -int ret;
>> +int ret = -ENOMEM;
>>  
>>  if (!cma || !cma->count)
>>  return NULL;
>> @@ -427,6 +427,33 @@ struct page *cma_alloc(struct cma *cma, size_t count, 
>> unsigned int align)
>>  trace_cma_alloc(pfn, page, count, align);
>>  
>>  pr_debug("%s(): returned %p\n", __func__, page);

This line should be moved after the ‘if (ret != 0)’ block, i.e. just
before return.

>> +
>> +if (ret != 0)
>
> you can simply do
>   if (!ret) {
>
>   pr_info("%s: alloc failed, req-size: %zu pages, ret: %d\n",
>   __func__, count, ret);
>   debug_show_cma_areas();
>   }
>
>   return page;
>
> static void debug_show_cma_areas(void)
> {
> #ifdef CONFIG_CMA_DEBUG
>   unsigned int nr, nr_total = 0;
>   unsigned long next_set_bit;
>
>   mutex_lock(&cma->lock);
>   pr_info("number of available pages: ");
>   start = 0;
>   for (;;) {
>   bitmap_no = find_next_zero_bit(cma->bitmap, cma->count, start);
>   if (bitmap_no >= cma->count)
>   break;
>   next_set_bit = find_next_bit(cma->bitmap, cma->count, 
> bitmap_no);
>   nr = next_set_bit - bitmap_no;
>   pr_cont("%s%u@%lu", nr_total ? "+" : "", nr, bitmap_no);
>   nr_total += nr;
>   start = bitmap_no + nr;
>   }
>   pr_cont("=>%u pages, total: %lu pages\n", nr_total, cma->count);

Perhaps:
pr_cont("=> %u free of %lu total pages\n", nr_total, cma->count);
or shorter (but more cryptic):
pr_cont("=> %u/%lu pages\n", nr_total, cma->count);

>   mutex_unlock(&cma->lock);
> #endif
> }

Actually, Linux style is more like:

#ifdef CONFIG_CMA_DEBUG
static void cma_debug_show_areas()
{
…
}
#else
static inline void cma_debug_show_areas() { }
#endif

>
> -- 
> Michal Hocko
> SUSE Labs

-- 
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»

Re: Nokia N900 sound driver and ECI GPIOs

[Pavel Machek]

Hi!

> I'm looking at original Maemo N900 2.6.28 sound driver and GPIOs which
> controls A/V jack detection.
> 
> For reference source code of that driver can be found e.g. at alsa-devel
> ML [1] [2] or in my linux-n900 git tree, branch v2.6.28-nokia [3].
> 
> In that sound/soc/omap/rx51.c code is function rx51_set_eci_switches()
> which configures 2 gpios: RX51_ECI_SWITCH_1_GPIO = gpio 178 and
> RX51_ECI_SWITCH_2_GPIO = gpio 182 based on "eci mode" input parameter.
> 
> But in mainline kernel code [4] [5] there is no information about gpio 178
> (as RX51_ECI_SWITCH_1_GPIO) and gpio 182 is called as just "eci-switch".
> More interesting part is that "eci-switch" gpio is not used in whole
> mainline code. It is just referenced in Nokia N900 DTS [4]. Looks like
> sound driver in mainline kernel is incomplete.
> 
> Jarkko, you are listed as original author of that driver. Do you (or
> anybody else) remember what that rx51_set_eci_switches() function is
> doing? And what gpio 178 controls? I was even not able to find gpio 178
> in RX-51 Schematics [6].
> 
> And do you know something about Nokia ECI headsets supports for Nokia
> N900. Looks like there is already some kernel code but support for ECI
> bus or multibuttons headset is missing.

What does "ECI" mean?

I'd like to get detection of headset button presses to work in recent
kernels, but could not figure it out :-(.

Are there multi-button headsets compatible with N900?

Best regards,
Pavel


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[PATCH 2/2] blackfin: ezbrd: Remove non-functional DSA/KSZ8893M code

[Florian Fainelli]

There is no in tree driver for the KSZ8893M switch driver, so just get rid of
the code in that board file.

Signed-off-by: Florian Fainelli 
---
 arch/blackfin/mach-bf518/boards/ezbrd.c | 47 -
 1 file changed, 47 deletions(-)

diff --git a/arch/blackfin/mach-bf518/boards/ezbrd.c 
b/arch/blackfin/mach-bf518/boards/ezbrd.c
index d022112927c2..c51d1b810ac3 100644
--- a/arch/blackfin/mach-bf518/boards/ezbrd.c
+++ b/arch/blackfin/mach-bf518/boards/ezbrd.c
@@ -25,7 +25,6 @@
 #include 
 #include 
 #include 
-#include 
 
 /*
  * Name the Board for the /proc/cpuinfo
@@ -105,11 +104,7 @@ static const unsigned short bfin_mac_peripherals[] = {
 
 static struct bfin_phydev_platform_data bfin_phydev_data[] = {
{
-#if IS_ENABLED(CONFIG_NET_DSA_KSZ8893M)
-   .addr = 3,
-#else
.addr = 1,
-#endif
.irq = IRQ_MAC_PHYINT,
},
 };
@@ -119,9 +114,6 @@ static struct bfin_mii_bus_platform_data bfin_mii_bus_data 
= {
.phydev_data = bfin_phydev_data,
.phy_mode = PHY_INTERFACE_MODE_MII,
.mac_peripherals = bfin_mac_peripherals,
-#if IS_ENABLED(CONFIG_NET_DSA_KSZ8893M)
-   .phy_mask = 0xfff7, /* Only probe the port phy connect to the on chip 
MAC */
-#endif
.vlan1_mask = 1,
.vlan2_mask = 2,
 };
@@ -140,29 +132,6 @@ static struct platform_device bfin_mac_device = {
}
 };
 
-#if IS_ENABLED(CONFIG_NET_DSA_KSZ8893M)
-static struct dsa_chip_data ksz8893m_switch_chip_data = {
-   .mii_bus = &bfin_mii_bus.dev,
-   .port_names = {
-   NULL,
-   "eth%d",
-   "eth%d",
-   "cpu",
-   },
-};
-static struct dsa_platform_data ksz8893m_switch_data = {
-   .nr_chips = 1,
-   .netdev = &bfin_mac_device.dev,
-   .chip = &ksz8893m_switch_chip_data,
-};
-
-static struct platform_device ksz8893m_switch_device = {
-   .name   = "dsa",
-   .id = 0,
-   .num_resources  = 0,
-   .dev.platform_data = &ksz8893m_switch_data,
-};
-#endif
 #endif
 
 #if IS_ENABLED(CONFIG_MTD_M25P80)
@@ -228,19 +197,6 @@ static struct spi_board_info bfin_spi_board_info[] 
__initdata = {
},
 #endif
 
-#if IS_ENABLED(CONFIG_BFIN_MAC)
-#if IS_ENABLED(CONFIG_NET_DSA_KSZ8893M)
-   {
-   .modalias = "ksz8893m",
-   .max_speed_hz = 500,
-   .bus_num = 0,
-   .chip_select = 1,
-   .platform_data = NULL,
-   .mode = SPI_MODE_3,
-   },
-#endif
-#endif
-
 #if IS_ENABLED(CONFIG_MMC_SPI)
{
.modalias = "mmc_spi",
@@ -714,9 +670,6 @@ static struct platform_device *stamp_devices[] __initdata = 
{
 #if IS_ENABLED(CONFIG_BFIN_MAC)
&bfin_mii_bus,
&bfin_mac_device,
-#if IS_ENABLED(CONFIG_NET_DSA_KSZ8893M)
-   &ksz8893m_switch_device,
-#endif
 #endif
 
 #if IS_ENABLED(CONFIG_SPI_BFIN5XX)
-- 
2.9.3

[PATCH 0/2] blackfin: Remove dead DSA code

[Florian Fainelli]

Hi all,

This patch series removes dead DSA code in the blackfin board specific
code. There is no in tree driver for the KSZ8893M, and clearly this
would not compile anymore.

Preparatory patch to help remove the legacy DSA platform device code from
the tree.

Florian Fainelli (2):
  blackfin: tcm-bf518: Remove dsa.h inclusion
  blackfin: ezbrd: Remove non-functional DSA/KSZ8893M code

 arch/blackfin/mach-bf518/boards/ezbrd.c | 47 -
 arch/blackfin/mach-bf518/boards/tcm-bf518.c |  1 -
 2 files changed, 48 deletions(-)

-- 
2.9.3

[PATCH 1/2] blackfin: tcm-bf518: Remove dsa.h inclusion

[Florian Fainelli]

Nothing in that file uses definitions from that header, so just get rid of it.

Signed-off-by: Florian Fainelli 
---
 arch/blackfin/mach-bf518/boards/tcm-bf518.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/blackfin/mach-bf518/boards/tcm-bf518.c 
b/arch/blackfin/mach-bf518/boards/tcm-bf518.c
index 240d5cb1f02c..37d868085f6a 100644
--- a/arch/blackfin/mach-bf518/boards/tcm-bf518.c
+++ b/arch/blackfin/mach-bf518/boards/tcm-bf518.c
@@ -25,7 +25,6 @@
 #include 
 #include 
 #include 
-#include 
 
 /*
  * Name the Board for the /proc/cpuinfo
-- 
2.9.3

drivers/auxdisplay/img-ascii-lcd.c:384: undefined reference to `devm_ioremap_resource'

[kbuild test robot]

Hi Paul,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   238d1d0f79f619d75c2cc741d6770fb0986aef24
commit: 0cad855fbd083ee5fd0584a47c2aaa7dca936fd4 auxdisplay: img-ascii-lcd: 
driver for simple ASCII LCD displays
date:   3 months ago
config: um-allyesconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 0cad855fbd083ee5fd0584a47c2aaa7dca936fd4
# save the attached .config to linux build tree
make ARCH=um 

All errors (new ones prefixed by >>):

   arch/um/drivers/built-in.o: In function `vde_open_real':
   (.text+0xc7d1): warning: Using 'getgrnam' in statically linked applications 
requires at runtime the shared libraries from the glibc version used for linking
   arch/um/drivers/built-in.o: In function `vde_open_real':
   (.text+0xc61c): warning: Using 'getpwuid' in statically linked applications 
requires at runtime the shared libraries from the glibc version used for linking
   arch/um/drivers/built-in.o: In function `vde_open_real':
   (.text+0xc935): warning: Using 'getaddrinfo' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametoaddr':
   (.text+0x1d3c5): warning: Using 'gethostbyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametonetaddr':
   (.text+0x1d465): warning: Using 'getnetbyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametoproto':
   (.text+0x1d685): warning: Using 'getprotobyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametoport':
   (.text+0x1d4b7): warning: Using 'getservbyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   drivers/built-in.o: In function `fwnode_get_named_gpiod':
   drivers/gpio/gpiolib.c:3215: undefined reference to 
`of_get_named_gpiod_flags'
   drivers/built-in.o: In function `gpiod_get_index':
   drivers/gpio/gpiolib.c:3140: undefined reference to 
`of_get_named_gpiod_flags'
   drivers/built-in.o: In function `lp872x_probe':
   drivers/regulator/lp872x.c:773: undefined reference to 
`devm_gpio_request_one'
   drivers/regulator/lp872x.c:746: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `max8952_pmic_probe':
   drivers/regulator/max8952.c:249: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `max8973_probe':
   drivers/regulator/max8973-regulator.c:715: undefined reference to 
`devm_gpio_request_one'
   drivers/regulator/max8973-regulator.c:770: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `pwm_regulator_probe':
   drivers/regulator/pwm-regulator.c:387: undefined reference to 
`devm_gpiod_get_optional'
   drivers/built-in.o: In function `tps62360_probe':
   drivers/regulator/tps62360-regulator.c:433: undefined reference to 
`devm_gpio_request_one'
   drivers/regulator/tps62360-regulator.c:444: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `fdp_nci_i2c_probe':
   drivers/nfc/fdp/i2c.c:326: undefined reference to `devm_gpiod_get'
   drivers/built-in.o: In function `nfcmrvl_nci_unregister_dev':
   drivers/nfc/nfcmrvl/main.c:198: undefined reference to `devm_gpio_free'
   drivers/built-in.o: In function `nfcmrvl_nci_register_dev':
   drivers/nfc/nfcmrvl/main.c:127: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `st21nfca_hci_i2c_probe':
   drivers/nfc/st21nfca/i2c.c:597: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `st_nci_i2c_probe':
   drivers/nfc/st-nci/i2c.c:300: undefined reference to `devm_gpio_request_one'
   drivers/built-in.o: In function `nxp_nci_i2c_probe':
   drivers/nfc/nxp-nci/i2c.c:361: undefined reference to `devm_gpio_request_one'
   drivers/built-in.o: In function `mdio_gpio_probe':
   drivers/net/phy/mdio-gpio.c:177: undefined reference to `devm_gpio_request'
   drivers/built-in.o: In function `at803x_probe':
   drivers/net/phy/at803x.c:283: undefined reference to 
`devm_gpiod_get_optional'
   drivers/built-in.o: In function `mv88e6xxx_probe':
   drivers/net/dsa/mv88e6xxx/chip.c:4028: undefined reference to 
`devm_gpiod_get_optional'
   drivers/built-in.o: In function `img_ascii_lcd_probe':
>> drivers/auxdisplay/img-ascii-lcd.c:384: undefined reference to 
>> `devm_ioremap_resource'
   drivers/built-in.o: In function `pps_gpio_probe':
   drivers/pps/clients/pps-gpio.c:125: undefined reference to 
`devm_gpio_request'
   dri

Linux 4.10-rc2

[Linus Torvalds]

Hey, it's been a really slow week between Christmas Day and New Years
Day, and I am not complaining at all.

It does mean that rc2 is ridiculously and unrealistically small. I
almost decided to skip rc2 entirely, but a small little meaningless
release every once in a while never hurt anybody. So here it is.

The only even remotely noticeable work here is the DAX fixups that
really arguably should have been merge window material but depended on
stuff during this merge window and were delayed until rc2 due to that.
Even that wasn't big, and the rest is trivial small fixes.

I'm expecting things to start picking up next week as people recover
from the holidays.

  Linus

---

Al Viro (1):
  arm64: don't pull uaccess.h into *.S

Chun-Hao Lin (1):
  r8169: add support for RTL8168 series add-on card.

Cihangir Akturk (1):
  Documentation/unaligned-memory-access.txt: fix incorrect
comparison operator

Daniel Borkmann (1):
  net, sched: fix soft lockup in tc_classify

Eric Dumazet (1):
  ipvlan: fix various issues in ipvlan_process_multicast()

Florian Fainelli (1):
  net: korina: Fix NAPI versus resources freeing

Haishuang Yan (1):
  ipv4: Namespaceify tcp_tw_reuse knob

Jan Kara (6):
  ext2: Return BH_New buffers for zeroed blocks
  mm: Invalidate DAX radix tree entries only if appropriate
  dax: Avoid page invalidation races and unnecessary radix tree traversals
  dax: Finish fault completely when loading holes
  dax: Call ->iomap_begin without entry lock during dax fault
  ext4: Simplify DAX fault path

Jason Wang (1):
  net: xdp: remove unused bfp_warn_invalid_xdp_buffer()

John Brooks (1):
  docs: Fix build failure

Jon Paul Maloy (1):
  tipc: don't send FIN message from connectionless socket

Kweh, Hock Leong (1):
  net: stmmac: fix incorrect bit set in gmac4 mdio addr register

Laura Abbott (1):
  crypto: testmgr - Use heap buffer for acomp test input

Linus Torvalds (2):
  mm: optimize PageWaiters bit use for unlock_page()
  Linux 4.10-rc2

Mahesh Bandewar (1):
  ipvlan: fix multicast processing

Olof Johansson (1):
  mm/filemap: fix parameters to test_bit()

Romain Perier (1):
  crypto: marvell - Copy IVDIG before launching partial DMA ahash requests

Tariq Toukan (1):
  net/mlx4_en: Fix user prio field in XDP forward

Thomas Gleixner (2):
  smp/hotplug: Undo tglxs brainfart
  x86/mce/AMD: Make the init code more robust

pravin shelar (1):
  openvswitch: upcall: Fix vlan handling.

Re: [BUG] 4.9 - kernel oops when pptp connection is established and the kernel doesn't have pptp modules compiled

[Ian Kumlien]

Sorry, after further inspection, it seems like the choice of
skb_header_pointer is wrong and skb isn't always populated. It seems
like the code has suffered from bitrot since all the surrounding code
is actually fixed.

This fixes it as well:
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index c6d8207ffa7e..32e4e0158846 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -445,8 +445,9 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
if (hdr->flags & GRE_ACK)
offset += sizeof(((struct
pptp_gre_header *)0)->ack);

-   ppp_hdr = skb_header_pointer(skb, nhoff + offset,
-sizeof(_ppp_hdr),
_ppp_hdr);
+   ppp_hdr = __skb_header_pointer(skb, nhoff + offset,
+sizeof(_ppp_hdr),
+data, hlen, _ppp_hdr);
if (!ppp_hdr)
goto out_bad;

Will send a patch with signed off by n' all.

On Sun, Jan 1, 2017 at 6:31 PM, Ian Kumlien  wrote:
> On Fri, Dec 30, 2016 at 11:48 PM, Ian Kumlien  wrote:
>> Hi,
>>
>> Been fighting with "crash" to get it to help me to analyze my crash
>> dumps... This is the output from vmcore-dmesg.
>>
>> This is 100% reproducible...
>>
>> Config that lets the connection trough but crashes the kernel:
>> # CONFIG_NF_CONNTRACK_PPTP is not set
>> # CONFIG_NF_NAT_PPTP is not set
>> CONFIG_PPTP=y
>>
>> If I enable the *_NF_* options, it doesn't crash but it also blocks
>> the PPTP packets.
>>
>> The crash is after the negotiation bit...
>
> So, some of the dumps pointed me, after some coaxing, to
> net/core/flow_dissector.c:448
> ---
> ppp_hdr = skb_header_pointer(skb, nhoff + offset,
>  sizeof(_ppp_hdr),
> _ppp_hdr);
> if (!ppp_hdr)
> goto out_bad;
> --
>
> Ie, copy or get the information from the skb to get more information
> on the pptp connection.
>
> However include/linux/skbuff.h:3109, with my test and debug code added
> static inline void * __must_check
> __skb_header_pointer(const struct sk_buff *skb, int offset,
>  int len, void *data, int hlen, void *buffer)
> {
> if (hlen - offset >= len)
> {
> if (skb == NULL || data == NULL)
> {
> printk("WARNING: something is null skb:%p
> data:%p - offset: %i hlen: %i len: %i\n", skb, data, offset, hlen,
> len);
> return NULL;
> }
> else
> return data + offset;
> }
>
> if (!skb ||
> skb_copy_bits(skb, offset, buffer, len) < 0)
> return NULL;
>
> return buffer;
> }
>
> static inline void * __must_check
> skb_header_pointer(const struct sk_buff *skb, int offset, int len, void 
> *buffer)
> {
> return __skb_header_pointer(skb, offset, len, skb->data,
> skb_headlen(skb), buffer);
> }
> ---
>
> so skb_header_pointer sends skb->data as data, but we never check if
> skb is *NULL*
>
> This does happen when we do a pptp connection:
> [   89.606712] WARNING: something is null skb:  (null)
> data:88bccc0d4000 - offset: 14 hlen: 256 len: 20
> [   89.613264] WARNING: something is null skb:  (null)
> data:88bccc00f800 - offset: 14 hlen: 256 len: 20
> [   89.621005] WARNING: something is null skb:  (null)
> data:88bccc010800 - offset: 14 hlen: 256 len: 20
> [   89.650479] WARNING: something is null skb:  (null)
> data:88bccc2cb000 - offset: 14 hlen: 256 len: 20
>
> So, the question is if the skb should always be there and always be
> valid? In that case something like this should fix it:
> static inline void * __must_check
> __skb_header_pointer(const struct sk_buff *skb, int offset,
>  int len, void *data, int hlen, void *buffer)
> {
> if (!skb)
> return NULL;
>
> if (hlen - offset >= len)
> return data + offset;
>
> if (skb_copy_bits(skb, offset, buffer, len) < 0)
> return NULL;
>
> return buffer;
> }
> ---
>
> Else the actual check would have to be moved to skb_header_pointer in
> this case - comments?
>
>> [  109.556866] BUG: unable to handle kernel NULL pointer dereference
>> at 0080
>> [  109.557102] IP: [] __skb_flow_dissect+0xa88/0xce0
>> [  109.557263] PGD 0
>> [  109.557338]
>> [  109.557484] Oops:  [#1] SMP
>> [  109.557562] Modules linked in: chaoskey
>> [  109.557783] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.9.0 #79
>> [  109.557867] Hardware name: Supermicro
>> A1SRM-LN7F/LN5F/A1SRM-LN7F-2758, BIOS 1.0c 11/04/2015
>> [  109.557957] task: 94085c27bc00 tas

Re: [PATCH] jump label: pass kbuild_cflags when checking for asm goto support

[David Lin]

+Cc: Steven Rostedt 
+Cc: Will Deacon 

On Fri, Dec 9, 2016 at 4:46 PM, David Lin  wrote:
> Some versions of ARM GCC compiler such as Android toolchain throws in a
> '-fpic' flag by default. This causes the gcc-goto check script to fail
> although some config would have '-fno-pic' flag in the KBUILD_CFLAGS.
>
> This patch passes the KBUILD_CFLAGS to the check script so that the
> script does not rely on the default config from different compilers.
>
> Signed-off-by: David Lin 
> ---
>  Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index 694111b..f667daa 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -790,7 +790,7 @@ KBUILD_CFLAGS   += $(call 
> cc-option,-Werror=incompatible-pointer-types)
>  KBUILD_ARFLAGS := $(call ar-option,D)
>
>  # check for 'asm goto'
> -ifeq ($(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-goto.sh $(CC)), y)
> +ifeq ($(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-goto.sh $(CC) 
> $(KBUILD_CFLAGS)), y)
> KBUILD_CFLAGS += -DCC_HAVE_ASM_GOTO
> KBUILD_AFLAGS += -DCC_HAVE_ASM_GOTO
>  endif
> --
> 2.10.2
>

[PATCH] Update pptp handling to avoid null pointer deref.

[Ian Kumlien]

__skb_flow_dissect can be called with a skb or a data packet, either
can be NULL. All calls seems to have been moved to __skb_header_pointer
except the pptp handling which is still calling skb_header_pointer.

skb_header_pointer will use skb->data and thus:
[  109.556866] BUG: unable to handle kernel NULL pointer dereference at 
0080
[  109.557102] IP: [] __skb_flow_dissect+0xa88/0xce0
[  109.557263] PGD 0
[  109.557338]
[  109.557484] Oops:  [#1] SMP
[  109.557562] Modules linked in: chaoskey
[  109.557783] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.9.0 #79
[  109.557867] Hardware name: Supermicro A1SRM-LN7F/LN5F/A1SRM-LN7F-2758, BIOS 
1.0c 11/04/2015
[  109.557957] task: 94085c27bc00 task.stack: b745c0068000
[  109.558041] RIP: 0010:[]  [] 
__skb_flow_dissect+0xa88/0xce0
[  109.558203] RSP: 0018:94087fc83d40  EFLAGS: 00010206
[  109.558286] RAX: 0130 RBX: 8975bf80 RCX: 94084fab6800
[  109.558373] RDX: 0010 RSI: 000c RDI: 
[  109.558460] RBP: 0b88 R08:  R09: 0022
[  109.558547] R10: 0008 R11: 94087fc83e04 R12: 
[  109.558763] R13: 94084fab6800 R14: 94087fc83e04 R15: 002f
[  109.558979] FS:  () GS:94087fc8() 
knlGS:
[  109.559326] CS:  0010 DS:  ES:  CR0: 80050033
[  109.559539] CR2: 0080 CR3: 000281809000 CR4: 001026e0
[  109.559753] Stack:
[  109.559957]  000c 94084fab6822 0001 
94085c2b5fc0
[  109.560578]  0001 2000  

[  109.561200]     

[  109.561820] Call Trace:
[  109.562027]  
[  109.562108]  [] ? eth_get_headlen+0x7a/0xf0
[  109.562522]  [] ? igb_poll+0x96a/0xe80
[  109.562737]  [] ? net_rx_action+0x20b/0x350
[  109.562953]  [] ? __do_softirq+0xe8/0x280
[  109.563169]  [] ? irq_exit+0xaa/0xb0
[  109.563382]  [] ? do_IRQ+0x4b/0xc0
[  109.563597]  [] ? common_interrupt+0x7f/0x7f
[  109.563810]  
[  109.563890]  [] ? cpuidle_enter_state+0x130/0x2c0
[  109.564304]  [] ? cpuidle_enter_state+0x120/0x2c0
[  109.564520]  [] ? cpu_startup_entry+0x19f/0x1f0
[  109.564737]  [] ? start_secondary+0x12a/0x140
[  109.564950] Code: 83 e2 20 a8 80 0f 84 60 01 00 00 c7 04 24 08 00
00 00 66 85 d2 0f 84 be fe ff ff e9 69 fe ff ff 8b 34 24 89 f2 83 c2
04 66 85 c0 <41> 8b 84 24 80 00 00 00 0f 49 d6 41 8d 31 01 d6 41 2b 84
24 84
[  109.569959] RIP  [] __skb_flow_dissect+0xa88/0xce0
[  109.570245]  RSP 
[  109.570453] CR2: 0080
---

Signed-off-by: Ian Kumlien 
---
 net/core/flow_dissector.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index c6d8207ffa7e..32e4e0158846 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -445,8 +445,9 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
if (hdr->flags & GRE_ACK)
offset += sizeof(((struct pptp_gre_header 
*)0)->ack);
 
-   ppp_hdr = skb_header_pointer(skb, nhoff + offset,
-sizeof(_ppp_hdr), 
_ppp_hdr);
+   ppp_hdr = __skb_header_pointer(skb, nhoff + offset,
+sizeof(_ppp_hdr),
+data, hlen, _ppp_hdr);
if (!ppp_hdr)
goto out_bad;
 
-- 
2.11.0

Auto-conversion of watchdog drivers to use devm functions

[Guenter Roeck]

Hi Wim,

With heavy support by Julia Lawall, I created a number of coccinelle scripts
to auto-convert watchdog platform drivers to use devm functions. The result
is quite impressive - many drivers won't even need remove functions anymore
after the conversion.

Question is now how to submit the patches. There are 12 rule files affecting
a total of 62 drivers. Should I submit one patch per driver (62 patches),
one patch per rule (12), or one patch per rule file per driver (183) ?

Also, how should I refer to the rules ? The total number of rule lines
is more than 1,000, which seems to be a bit much for the commit log (even
though not all rules apply to all files).

Thanks,
Guenter

[PATCH] drm: nouveau: fix build when LEDS_CLASS=m

[Randy Dunlap]

From: Randy Dunlap 

Fix build errors in nouveau driver when CONFIG_LEDS_CLASS=m and
CONFIG_DRM_NOUVEAU=y.
If LEDS_CLASS is enabled, DRM_NOUVEAU is restricted to the same
kconfig value as LEDS_CLASS.

drivers/built-in.o: In function `nouveau_do_suspend':
nouveau_drm.c:(.text+0x2030b1): undefined reference to `nouveau_led_suspend'
drivers/built-in.o: In function `nouveau_do_resume':
nouveau_drm.c:(.text+0x2034ca): undefined reference to `nouveau_led_resume'
drivers/built-in.o: In function `nouveau_drm_unload':
nouveau_drm.c:(.text+0x203a15): undefined reference to `nouveau_led_fini'
drivers/built-in.o: In function `nouveau_drm_load':
nouveau_drm.c:(.text+0x204423): undefined reference to `nouveau_led_init'

BTW, this line in Kbuild:
nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o
does nothing when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y.

Signed-off-by: Randy Dunlap 
Reported-by: kbuild test robot 
Cc: Martin Peres 
Cc: Ben Skeggs 
---
 drivers/gpu/drm/nouveau/Kconfig |1 +
 1 file changed, 1 insertion(+)

--- lnx-410-rc2.orig/drivers/gpu/drm/nouveau/Kconfig
+++ lnx-410-rc2/drivers/gpu/drm/nouveau/Kconfig
@@ -1,6 +1,7 @@
 config DRM_NOUVEAU
tristate "Nouveau (NVIDIA) cards"
depends on DRM && PCI
+   depends on LEDS_CLASS || LEDS_CLASS=n
 select FW_LOADER
select DRM_KMS_HELPER
select DRM_TTM

drivers/mtd/nand/oxnas_nand.c:102: undefined reference to `devm_ioremap_resource'

[kbuild test robot]

Hi Neil,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   0c744ea4f77d72b3dcebb7a8f2684633ec79be88
commit: 668592492409498afc277da41e84799e1d2255c2 mtd: nand: Add OX820 NAND 
Support
date:   2 months ago
config: um-allyesconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 668592492409498afc277da41e84799e1d2255c2
# save the attached .config to linux build tree
make ARCH=um 

All errors (new ones prefixed by >>):

   arch/um/drivers/built-in.o: In function `vde_open_real':
   (.text+0xc7d1): warning: Using 'getgrnam' in statically linked applications 
requires at runtime the shared libraries from the glibc version used for linking
   arch/um/drivers/built-in.o: In function `vde_open_real':
   (.text+0xc61c): warning: Using 'getpwuid' in statically linked applications 
requires at runtime the shared libraries from the glibc version used for linking
   arch/um/drivers/built-in.o: In function `vde_open_real':
   (.text+0xc935): warning: Using 'getaddrinfo' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametoaddr':
   (.text+0x1d3c5): warning: Using 'gethostbyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametonetaddr':
   (.text+0x1d465): warning: Using 'getnetbyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametoproto':
   (.text+0x1d685): warning: Using 'getprotobyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametoport':
   (.text+0x1d4b7): warning: Using 'getservbyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   drivers/built-in.o: In function `lp872x_probe':
   drivers/regulator/lp872x.c:773: undefined reference to 
`devm_gpio_request_one'
   drivers/regulator/lp872x.c:746: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `max8952_pmic_probe':
   drivers/regulator/max8952.c:249: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `max8973_probe':
   drivers/regulator/max8973-regulator.c:716: undefined reference to 
`devm_gpio_request_one'
   drivers/regulator/max8973-regulator.c:771: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `pwm_regulator_probe':
   drivers/regulator/pwm-regulator.c:377: undefined reference to 
`devm_gpiod_get_optional'
   drivers/built-in.o: In function `tps62360_probe':
   drivers/regulator/tps62360-regulator.c:433: undefined reference to 
`devm_gpio_request_one'
   drivers/regulator/tps62360-regulator.c:444: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `fdp_nci_i2c_probe':
   drivers/nfc/fdp/i2c.c:326: undefined reference to `devm_gpiod_get'
   drivers/built-in.o: In function `nfcmrvl_nci_unregister_dev':
   drivers/nfc/nfcmrvl/main.c:198: undefined reference to `devm_gpio_free'
   drivers/built-in.o: In function `nfcmrvl_nci_register_dev':
   drivers/nfc/nfcmrvl/main.c:127: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `st21nfca_hci_i2c_probe':
   drivers/nfc/st21nfca/i2c.c:597: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `st_nci_i2c_probe':
   drivers/nfc/st-nci/i2c.c:300: undefined reference to `devm_gpio_request_one'
   drivers/built-in.o: In function `nxp_nci_i2c_probe':
   drivers/nfc/nxp-nci/i2c.c:361: undefined reference to `devm_gpio_request_one'
   drivers/built-in.o: In function `oxnas_nand_probe':
>> drivers/mtd/nand/oxnas_nand.c:102: undefined reference to 
>> `devm_ioremap_resource'
   drivers/built-in.o: In function `mdio_gpio_probe':
   drivers/net/phy/mdio-gpio.c:177: undefined reference to `devm_gpio_request'
   drivers/built-in.o: In function `at803x_probe':
   drivers/net/phy/at803x.c:283: undefined reference to 
`devm_gpiod_get_optional'
   drivers/built-in.o: In function `mv88e6xxx_probe':
   drivers/net/dsa/mv88e6xxx/chip.c:3832: undefined reference to 
`devm_gpiod_get_optional'
   drivers/built-in.o: In function `img_ascii_lcd_probe':
   drivers/auxdisplay/img-ascii-lcd.c:384: undefined reference to 
`devm_ioremap_resource'
   drivers/built-in.o: In function `pps_gpio_probe':
   drivers/pps/clients/pps-gpio.c:125: undefined reference to 
`devm_gpio_request'
   drivers/built-in.o: In function `sbs_probe':
   drivers/power/supply/sbs-battery.c:803: undefined reference to 
`devm_gpiod_get_optional'
   drivers/built-in.o: In function 

[GIT PULL] Openrisc fixes for 4.10

[Stafford Horne]

Hi Linus, 

Please pull the below for Openrisc, There was nothing much interesting
here except a build fix pointed out by the test robots. Highlights:

 - Defined _text symbol for fix build error

-Stafford


The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:

  Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)

are available in the git repository at:

  https://github.com/openrisc/linux.git tags/openrisc-for-linus

for you to fetch changes up to 086cc1c31a0ec075dac02425367c871bb65bc2c9:

  openrisc: Add _text symbol to fix ksym build error (2017-01-02
10:35:11 +0900)


Openrisc more fixes for 4.10


Stafford Horne (1):
  openrisc: Add _text symbol to fix ksym build error

 arch/openrisc/kernel/vmlinux.lds.S | 2 ++
 1 file changed, 2 insertions(+)

[PATCH 8/8] ARM: dts: kirkwood-rd88f6281: Utilize new DSA binding

[Florian Fainelli]

Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net: dsa:
Document new binding"). The legacy binding node is kept included, but is marked
disabled.

Signed-off-by: Florian Fainelli 
---
 arch/arm/boot/dts/kirkwood-rd88f6281-z0.dts | 11 
 arch/arm/boot/dts/kirkwood-rd88f6281.dtsi   | 44 +
 2 files changed, 55 insertions(+)

diff --git a/arch/arm/boot/dts/kirkwood-rd88f6281-z0.dts 
b/arch/arm/boot/dts/kirkwood-rd88f6281-z0.dts
index 1a797381d3d4..57cfcc2941cd 100644
--- a/arch/arm/boot/dts/kirkwood-rd88f6281-z0.dts
+++ b/arch/arm/boot/dts/kirkwood-rd88f6281-z0.dts
@@ -33,3 +33,14 @@
 ð1 {
   status = "disabled";
 };
+
+&switch {
+   reg = <0>;
+
+   ports {
+   port@4 {
+   reg = <4>;
+   label = "wan";
+   };
+   };  
+};
diff --git a/arch/arm/boot/dts/kirkwood-rd88f6281.dtsi 
b/arch/arm/boot/dts/kirkwood-rd88f6281.dtsi
index d5aacf137e40..91f5da5dae5f 100644
--- a/arch/arm/boot/dts/kirkwood-rd88f6281.dtsi
+++ b/arch/arm/boot/dts/kirkwood-rd88f6281.dtsi
@@ -54,6 +54,8 @@
};
 
dsa {
+   status = "disabled";
+
compatible = "marvell,dsa";
#address-cells = <2>;
#size-cells = <0>;
@@ -115,6 +117,48 @@
 
 &mdio {
status = "okay";
+
+   switch: switch@0 {
+   compatible = "marvell,mv88e6085";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   label = "lan1";
+   };
+
+   port@1 {
+   reg = <1>;
+   label = "lan2";
+   };
+
+   port@2 {
+   reg = <2>;
+   label = "lan3";
+   };
+
+   port@3 {
+   reg = <3>;
+   label = "lan4";
+   };
+
+   port@5 {
+   reg = <5>;
+   label = "cpu";
+   ethernet = <ð0port>;
+   fixed-link {
+   speed = <1000>;
+   full-duplex;
+   };
+   };
+
+   };
+   };
 };
 
 ð0 {
-- 
2.9.3

[PATCH 0/8] ARM: dts: Switch to new DSA binding

[Florian Fainelli]

Hi all,

This patch series converts the in-tree users to utilize the new (relatively)
DSA binding that was introduced with commit 8c5ad1d6179d ("net: dsa: Document
new binding"). The legacy binding node is kept included, but is marked
disabled.

In about 2-3 releases we may consider removing the old DSA binding entirely
from the kernel.

Thank you!

Florian Fainelli (8):
  ARM: dts: armada-370-rd: Utilize new DSA binding
  ARM: dts: armada-38x: Utilize new DSA binding
  ARM: dts: armada-388-clearfog: Utilize new DSA binding
  ARM: dts: armada-xp-linksys-mamba: Utilize new DSA binding
  ARM: dts: kirkwood-dir665: Utilize new DSA binding
  ARM: dts: kirkwood-linksys-viper: Utilize new DSA binding
  ARM: dts: kirkwood-mv88f6281gtw-ge: Utilize new DSA binding
  ARM: dts: kirkwood-rd88f6281: Utilize new DSA binding

 arch/arm/boot/dts/armada-370-rd.dts| 44 +
 arch/arm/boot/dts/armada-385-linksys.dtsi  | 52 -
 arch/arm/boot/dts/armada-388-clearfog.dts  | 65 ++
 arch/arm/boot/dts/armada-xp-linksys-mamba.dts  | 53 +
 arch/arm/boot/dts/kirkwood-dir665.dts  | 49 +++
 arch/arm/boot/dts/kirkwood-linksys-viper.dts   | 49 +++
 arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts | 49 +++
 arch/arm/boot/dts/kirkwood-rd88f6281-z0.dts| 11 +
 arch/arm/boot/dts/kirkwood-rd88f6281.dtsi  | 44 +
 9 files changed, 415 insertions(+), 1 deletion(-)

-- 
2.9.3

[PATCH 2/8] ARM: dts: armada-38x: Utilize new DSA binding

[Florian Fainelli]

Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net: dsa:
Document new binding"). The legacy binding node is kept included, but is marked
disabled.

Signed-off-by: Florian Fainelli 
---
 arch/arm/boot/dts/armada-385-linksys.dtsi | 52 ++-
 1 file changed, 51 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/armada-385-linksys.dtsi 
b/arch/arm/boot/dts/armada-385-linksys.dtsi
index 8f0e508f64ae..20d5e8b00f2d 100644
--- a/arch/arm/boot/dts/armada-385-linksys.dtsi
+++ b/arch/arm/boot/dts/armada-385-linksys.dtsi
@@ -103,8 +103,56 @@
};
};
 
-   mdio {
+   mdio@72004 {
status = "okay";
+
+   switch@0 {
+   compatible = "marvell,mv88e6095";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   label = "lan4";
+   };
+
+   port@1 {
+   reg = <1>;
+   label = "lan3";
+   };
+
+   port@2 {
+   reg = <2>;
+   label = "lan2";
+   };
+
+   port@3 {
+   reg = <3>;
+   label = "lan1";
+   };
+
+   port@4 {
+   reg = <4>;
+   label = "wan";
+   };
+
+   port@5 {
+   reg = <5>;
+   label = "cpu";
+   ethernet = <ð2>;
+
+   fixed-link {
+   speed = <1000>;
+   full-duplex;
+   };
+   };
+   };
+   };
};
 
sata@a8000 {
@@ -261,6 +309,8 @@
};
 
dsa@0 {
+   status = "disabled";
+
compatible = "marvell,dsa";
#address-cells = <2>;
#size-cells = <0>;
-- 
2.9.3

[PATCH 7/8] ARM: dts: kirkwood-mv88f6281gtw-ge: Utilize new DSA binding

[Florian Fainelli]

Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net: dsa:
Document new binding"). The legacy binding node is kept included, but is marked
disabled.

Signed-off-by: Florian Fainelli 
---
 arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts | 49 ++
 1 file changed, 49 insertions(+)

diff --git a/arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts 
b/arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts
index 172a38c0b8a9..5622115158ab 100644
--- a/arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts
+++ b/arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts
@@ -112,6 +112,8 @@
};
 
dsa {
+   status = "disabled";
+
compatible = "marvell,dsa";
#address-cells = <1>;
#size-cells = <0>;
@@ -159,6 +161,53 @@
 
 &mdio {
status = "okay";
+
+   switch@0 {
+   compatible = "marvell,mv88e6085";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   label = "lan1";
+   };
+
+   port@1 {
+   reg = <1>;
+   label = "lan2";
+   };
+
+   port@2 {
+   reg = <2>;
+   label = "lan3";
+   };
+
+   port@3 {
+   reg = <3>;
+   label = "lan4";
+   };
+
+   port@4 {
+   reg = <4>;
+   label = "wan";
+   };
+
+   port@5 {
+   reg = <5>;
+   label = "cpu";
+   ethernet = <ð0port>;
+   fixed-link {
+   speed = <1000>;
+   full-duplex;
+   };
+   };
+   };
+   };  
 };
 
 ð0 {
-- 
2.9.3

[PATCH 3/8] ARM: dts: armada-388-clearfog: Utilize new DSA binding

[Florian Fainelli]

Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net:
dsa: Document new binding"). The legacy binding node is kept included, but is
marked disabled.

Signed-off-by: Florian Fainelli 
---
 arch/arm/boot/dts/armada-388-clearfog.dts | 65 +++
 1 file changed, 65 insertions(+)

diff --git a/arch/arm/boot/dts/armada-388-clearfog.dts 
b/arch/arm/boot/dts/armada-388-clearfog.dts
index 71ce201c903e..35207aa1f4ec 100644
--- a/arch/arm/boot/dts/armada-388-clearfog.dts
+++ b/arch/arm/boot/dts/armada-388-clearfog.dts
@@ -351,6 +351,8 @@
};
 
dsa@0 {
+   status = "okay";
+
compatible = "marvell,dsa";
dsa,ethernet = <ð1>;
dsa,mii-bus = <&mdio>;
@@ -444,3 +446,66 @@
status = "disabled";
};
 };
+
+&mdio {
+   status = "okay";
+
+   switch@4 {
+   compatible = "marvell,mv88e6085";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <4>;
+   pinctrl-0 = <&clearfog_dsa0_clk_pins &clearfog_dsa0_pins>;
+   pinctrl-names = "default";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   label = "lan5";
+   };
+
+   port@1 {
+   reg = <1>;
+   label = "lan4";
+   };
+
+   port@2 {
+   reg = <2>;
+   label = "lan3";
+   };
+
+   port@3 {
+   reg = <3>;
+   label = "lan2";
+   };
+
+   port@4 {
+   reg = <4>;
+   label = "lan1";
+   };
+
+   port@5 {
+   reg = <5>;
+   label = "cpu";
+   ethernet = <ð1>;
+   fixed-link {
+   speed = <1000>;
+   full-duplex;
+   };
+   };
+
+   port@6 {
+   /* 88E1512 external phy */
+   reg = <6>;
+   label = "lan6";
+   fixed-link {
+   speed = <1000>;
+   full-duplex;
+   };
+   };
+   };
+   };
+};
-- 
2.9.3

[PATCH 6/8] ARM: dts: kirkwood-linksys-viper: Utilize new DSA binding

[Florian Fainelli]

Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net: dsa:
Document new binding"). The legacy binding node is kept included, but is marked
disabled.

Signed-off-by: Florian Fainelli 
---
 arch/arm/boot/dts/kirkwood-linksys-viper.dts | 49 
 1 file changed, 49 insertions(+)

diff --git a/arch/arm/boot/dts/kirkwood-linksys-viper.dts 
b/arch/arm/boot/dts/kirkwood-linksys-viper.dts
index 345fcac48dc7..df7851820507 100644
--- a/arch/arm/boot/dts/kirkwood-linksys-viper.dts
+++ b/arch/arm/boot/dts/kirkwood-linksys-viper.dts
@@ -70,6 +70,8 @@
};
 
dsa {
+   status = "disabled";
+
compatible = "marvell,dsa";
#address-cells = <2>;
#size-cells = <0>;
@@ -207,6 +209,53 @@
 
 &mdio {
status = "okay";
+
+   switch@10 {
+   compatible = "marvell,mv88e6085";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <16>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   label = "ethernet1";
+   };
+
+   port@1 {
+   reg = <1>;
+   label = "ethernet2";
+   };
+
+   port@2 {
+   reg = <2>;
+   label = "ethernet3";
+   };
+
+   port@3 {
+   reg = <3>;
+   label = "ethernet4";
+   };
+
+   port@4 {
+   reg = <4>;
+   label = "internet";
+   };
+
+   port@5 {
+   reg = <5>;
+   label = "cpu";
+   ethernet = <ð0port>;
+   fixed-link {
+   speed = <1000>;
+   full-duplex;
+   };
+   };
+   };
+   };
 };
 
 &uart0 {
-- 
2.9.3

[PATCH 4/8] ARM: dts: armada-xp-linksys-mamba: Utilize new DSA binding

[Florian Fainelli]

Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net: dsa:
Document new binding"). The legacy binding node is kept included, but is marked
disabled.

Signed-off-by: Florian Fainelli 
---
 arch/arm/boot/dts/armada-xp-linksys-mamba.dts | 53 +++
 1 file changed, 53 insertions(+)

diff --git a/arch/arm/boot/dts/armada-xp-linksys-mamba.dts 
b/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
index 83ac884c0f8a..42ea8764814c 100644
--- a/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
+++ b/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
@@ -302,6 +302,8 @@
};
 
dsa {
+   status = "disabled";
+
compatible = "marvell,dsa";
#address-cells = <2>;
#size-cells = <0>;
@@ -398,3 +400,54 @@
spi-max-frequency = <4000>;
};
 };
+
+&mdio {
+   status = "okay";
+
+   switch@0 {
+   compatible = "marvell,mv88e6085";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   label = "lan4";
+   };
+
+   port@1 {
+   reg = <1>;
+   label = "lan3";
+   };
+
+   port@2 {
+   reg = <2>;
+   label = "lan2";
+   };
+
+   port@3 {
+   reg = <3>;
+   label = "lan1";
+   };
+
+   port@4 {
+   reg = <4>;
+   label = "internet";
+   };
+
+   port@5 {
+   reg = <5>;
+   label = "cpu";
+   ethernet = <ð0>;
+   fixed-link {
+   speed = <1000>;
+   full-duplex;
+   };
+   };
+   };
+   };
+};
-- 
2.9.3

[PATCH 5/8] ARM: dts: kirkwood-dir665: Utilize new DSA binding

[Florian Fainelli]

Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net: dsa:
Document new binding"). The legacy binding node is kept included, but is marked
disabled.

Signed-off-by: Florian Fainelli 
---
 arch/arm/boot/dts/kirkwood-dir665.dts | 49 +++
 1 file changed, 49 insertions(+)

diff --git a/arch/arm/boot/dts/kirkwood-dir665.dts 
b/arch/arm/boot/dts/kirkwood-dir665.dts
index 41acbb6dd6ab..4d2b15d6244a 100644
--- a/arch/arm/boot/dts/kirkwood-dir665.dts
+++ b/arch/arm/boot/dts/kirkwood-dir665.dts
@@ -194,6 +194,8 @@
};
 
dsa {
+   status = "disabled";
+
compatible = "marvell,dsa";
#address-cells = <2>;
#size-cells = <0>;
@@ -241,6 +243,53 @@
 
 &mdio {
status = "okay";
+
+   switch@0 {
+   compatible = "marvell,mv88e6085";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   label = "lan4";
+   };
+
+   port@1 {
+  reg = <1>;
+  label = "lan3";
+   };
+
+   port@2 {
+  reg = <2>;
+  label = "lan2";
+   };
+
+   port@3 {
+  reg = <3>;
+  label = "lan1";
+   };
+
+   port@4 {
+   reg = <4>;
+   label = "wan";
+   };
+
+   port@6 {
+   reg = <6>;
+   label = "cpu";
+   ethernet = <ð0port>;
+   fixed-link {
+   speed = <1000>;
+   full-duplex;
+   };
+   };
+   };
+   };
 };
 
 /* eth0 is connected to a Marvell 88E6171 switch, without a PHY. So set
-- 
2.9.3

[PATCH 1/8] ARM: dts: armada-370-rd: Utilize new DSA binding

[Florian Fainelli]

Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net: dsa:
Document new binding"). The legacy binding node is kept included, but is marked
disabled.

Signed-off-by: Florian Fainelli 
---
 arch/arm/boot/dts/armada-370-rd.dts | 44 +
 1 file changed, 44 insertions(+)

diff --git a/arch/arm/boot/dts/armada-370-rd.dts 
b/arch/arm/boot/dts/armada-370-rd.dts
index c3fd6e49212f..9c6e924ac0b3 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -173,6 +173,8 @@
};
 
dsa {
+   status = "disabled";
+
compatible = "marvell,dsa";
#address-cells = <2>;
#size-cells = <0>;
@@ -235,6 +237,48 @@
phy0: ethernet-phy@0 {
reg = <0>;
};
+
+   switch: switch@10 {
+   compatible = "marvell,mv88e6085";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <16>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   label = "lan0";
+   };
+
+   port@1 {
+  reg = <1>;
+  label = "lan1";
+   };
+
+   port@2 {
+  reg = <2>;
+  label = "lan2";
+   };
+
+   port@3 {
+  reg = <3>;
+  label = "lan3";
+   };
+
+   port@5 {
+   reg = <5>;
+   label = "cpu";
+   ethernet = <ð1>;
+   fixed-link {
+   speed = <1000>;
+   full-duplex;
+   };
+   };
+   };
+   };
 };
 
 
-- 
2.9.3

[PATCH] taint/module: Fix problems when out-of-kernel driver defines true or false

[Larry Finger]

Commit 7fd8329ba502 ("taint/module: Clean up global and module taint
flags handling") used the key words true and false as character members
of a new struct. These names cause problems when out-of-kernel modules
such as VirtualBox include their own definitions of true and false.

Fixes: 7fd8329ba502 ("taint/module: Clean up global and module taint flags 
handling")
Signed-off-by: Larry Finger 
Cc: Petr Mladek 
Cc: Jessica Yu 
Cc: Rusty Russell 
---
 include/linux/kernel.h | 4 ++--
 kernel/module.c| 2 +-
 kernel/panic.c | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 56aec84..cb09238 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -514,8 +514,8 @@ extern enum system_states {
 #define TAINT_FLAGS_COUNT  16
 
 struct taint_flag {
-   char true;  /* character printed when tainted */
-   char false; /* character printed when not tainted */
+   char c_true;/* character printed when tainted */
+   char c_false;   /* character printed when not tainted */
bool module;/* also show as a per-module taint flag */
 };
 
diff --git a/kernel/module.c b/kernel/module.c
index f7482db..5f7d482 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1145,7 +1145,7 @@ static size_t module_flags_taint(struct module *mod, char 
*buf)
 
for (i = 0; i < TAINT_FLAGS_COUNT; i++) {
if (taint_flags[i].module && test_bit(i, &mod->taints))
-   buf[l++] = taint_flags[i].true;
+   buf[l++] = taint_flags[i].c_true;
}
 
return l;
diff --git a/kernel/panic.c b/kernel/panic.c
index c51edaa..901c4fb 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -355,7 +355,7 @@ const char *print_tainted(void)
for (i = 0; i < TAINT_FLAGS_COUNT; i++) {
const struct taint_flag *t = &taint_flags[i];
*s++ = test_bit(i, &tainted_mask) ?
-   t->true : t->false;
+   t->c_true : t->c_false;
}
*s = 0;
} else
-- 
2.10.2

RE: [RFC] memcpy_nocache() and memcpy_writethrough()

[Elliott, Robert (Persistent Memory)]

> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Al Viro
> Sent: Friday, December 30, 2016 8:26 PM
> Subject: [RFC] memcpy_nocache() and memcpy_writethrough()
> 
...
> Why does pmem need writethrough warranties, anyway?  

Using either 
* nontemporal store instructions; or
* following regular store instructions with a sequence of cache flush
and store fence instructions (e.g., clflushopt or clwb + sfence)

ensures that write data has reached an "ADR-safe zone" that the system
promises will be persistent even if there is a surprise power loss or
a CPU suffers from an error that isn't totally catastrophic (e.g., the
CPU getting disconnected from the SDRAM will always lose data on an
NVDIMM-N).

The ACPI NFIT Flush Hints provide a guarantee that data is safe even
in the case of a CPU error, but that feature is not present in all
systems for all types of persistent memory.

> All explanations I've found on the net had been along the lines of
> "we should not store a pointer to pmem data structure until the
> structure itself had been committed to pmem itself" and it looks
> like something that ought to be a job for barriers - after all,
> we don't want the pointer store to be observed by _anything_
> in the system until the earlier stores are visible, so what makes
> pmem different from e.g. another CPU or a PCI busmaster, or...

Newly written data becomes globally visible before it becomes ADR-safe.
This means software could act on the new data before a power loss, then
see the old data reappear after the power loss - not good.  Software
needs to understand that any data in the process of being written is
indeterminate until the persistence guarantee is met.  The BTT shows
one way that software can avoid that problem.

---
Robert Elliott, HPE Persistent Memory

[PATCH] auxdisplay: img-ascii-lcd: don't build without HAS_IOMEM

[Randy Dunlap]

From: Randy Dunlap 

Fix build error when the driver is built for arch/um, which does not
support HAS_IOMEM. Furthermore, the in-tree SYSCON drivers also require
HAS_IOMEM.

drivers/built-in.o: In function `img_ascii_lcd_probe':
drivers/auxdisplay/img-ascii-lcd.c:384: undefined reference to 
`devm_ioremap_resource'

Paul: there is no SYSCON kconfig symbol in the kernel tree. Should that
be MFD_SYSCON or GPIO_SYSCON?
Also, there is no MIPS_SEAD3 kconfig symbol either. Please fix that.

Signed-off-by: Randy Dunlap 
Reported-by: kbuild test robot 
Cc: Paul Burton 
Cc: Jeff Dike 
Cc: Richard Weinberger 
Cc: user-mode-linux-de...@lists.sourceforge.net
Cc: Lee Jones 
Cc: Arnd Bergmann 
Cc: Geert Uytterhoeven 
Cc: Ralf Baechle 
---
 drivers/auxdisplay/Kconfig |1 +
 1 file changed, 1 insertion(+)

--- lnx-410-rc2.orig/drivers/auxdisplay/Kconfig
+++ lnx-410-rc2/drivers/auxdisplay/Kconfig
@@ -121,6 +121,7 @@ config CFAG12864B_RATE
 
 config IMG_ASCII_LCD
tristate "Imagination Technologies ASCII LCD Display"
+   depends on HAS_IOMEM
default y if MIPS_MALTA || MIPS_SEAD3
select SYSCON
help

[PATCH] mtd: nand: oxnas_nand: fix build errors on arch/um, require HAS_IOMEM

[Randy Dunlap]

From: Randy Dunlap 

Fix build errors on arch/um, which does not support HAS_IOMEM,
while the oxnas_nand.c driver uses interfaces that are
supplied by HAS_IOMEM.

(loadable module build:)
ERROR: "devm_ioremap_resource" [drivers/mtd/nand/oxnas_nand.ko] undefined!
or (built-in build:)
drivers/built-in.o: In function `oxnas_nand_probe':
drivers/mtd/nand/oxnas_nand.c:102: undefined reference to 
`devm_ioremap_resource'

Signed-off-by: Randy Dunlap 
Reported-by: kbuild test robot 
Cc: Boris Brezillon 
Cc: Neil Armstrong 
Cc: Jeff Dike 
Cc: Richard Weinberger 
Cc: user-mode-linux-de...@lists.sourceforge.net
Cc: linux-...@lists.infradead.org
---
 drivers/mtd/nand/Kconfig |1 +
 1 file changed, 1 insertion(+)

--- lnx-410-rc2.orig/drivers/mtd/nand/Kconfig
+++ lnx-410-rc2/drivers/mtd/nand/Kconfig
@@ -426,6 +426,7 @@ config MTD_NAND_ORION
 
 config MTD_NAND_OXNAS
tristate "NAND Flash support for Oxford Semiconductor SoC"
+   depends on HAS_IOMEM
help
  This enables the NAND flash controller on Oxford Semiconductor SoCs.
 

Re: [PATCH] drop_monitor: add missing call to genlmsg_end

[David Miller]

From: Reiter Wolfgang 
Date: Sat, 31 Dec 2016 21:11:57 +0100

> Update nlmsg_len field with genlmsg_end to enable userspace processing
> using nlmsg_next helper. Also adds error handling.
> 
> Signed-off-by: Reiter Wolfgang 

Applied and queued up for -stable, thanks.

Re: [PATCH] Update pptp handling to avoid null pointer deref.

[David Miller]

From: Ian Kumlien 
Date: Mon,  2 Jan 2017 00:19:36 +0100

> __skb_flow_dissect can be called with a skb or a data packet, either
> can be NULL. All calls seems to have been moved to __skb_header_pointer
> except the pptp handling which is still calling skb_header_pointer.
> 
> skb_header_pointer will use skb->data and thus:
 ...
> ---
> 
> Signed-off-by: Ian Kumlien 

You need to fix some parts of your submission.

Do not put the signoff after the "---", git will remove all text
after that "---" from the commit message.

You must include a proper "Fixes: " tag which indicates which change
introduced this regression.  This is critical for analyzing your fix
and also for figuring out which -stable releases your fix should be
backported to.

In this case the guilty commit is ab10dccb1160 ("rps: Inspect PPTP
encapsulated by GRE to get flow hash")

Re: [PATCH 0/9] dmaengine: stm32-dma: Bug fixes and improvements series

[Vinod Koul]

On Tue, Dec 13, 2016 at 02:40:42PM +0100, M'boumba Cedric Madianga wrote:
> This patchset adds bug fixes reported by devices using STM32 DMA and some
> improvements mainly linked to dmaengine framework evolution.

So you should order fixes first and then new additions.

Fixes go in for current release whereas the rest for next one.

I have applied two to fixes and rest to updated, patch 5 didn't apply, please
resend that one.

-- 
~Vinod

Re: [PATCH] dmaengine: Convert ID allocation to an IDA

[Vinod Koul]

On Thu, Dec 15, 2016 at 08:57:51AM -0800, Matthew Wilcox wrote:
> From: Matthew Wilcox 
> 
> dmaengine currently uses an IDR to allocate DMA IDs, but it only needs
> to know whether IDs are in use or not; the ID to pointer functionality
> of the IDR is unused.  That means it can use the more space-efficient IDA.

Applied, thanks

-- 
~Vinod

Re: [PATCH] dmaengine: ti-dma-crossbar: Add some 'of_node_put()' in error path.

[Vinod Koul]

On Mon, Dec 19, 2016 at 06:33:51AM +0100, Christophe JAILLET wrote:
> Add some missing 'of_node_put()' in early exit error path.

Applied, Thanks

-- 
~Vinod

Re: [RFC] memcpy_nocache() and memcpy_writethrough()

[Al Viro]

On Mon, Jan 02, 2017 at 02:35:36AM +, Elliott, Robert (Persistent Memory) 
wrote:
> > -Original Message-
> > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> > ow...@vger.kernel.org] On Behalf Of Al Viro
> > Sent: Friday, December 30, 2016 8:26 PM
> > Subject: [RFC] memcpy_nocache() and memcpy_writethrough()
> > 
> ...
> > Why does pmem need writethrough warranties, anyway?  
> 
> Using either 
> * nontemporal store instructions; or
> * following regular store instructions with a sequence of cache flush
> and store fence instructions (e.g., clflushopt or clwb + sfence)
> 
> ensures that write data has reached an "ADR-safe zone" that the system
> promises will be persistent even if there is a surprise power loss or
> a CPU suffers from an error that isn't totally catastrophic (e.g., the
> CPU getting disconnected from the SDRAM will always lose data on an
> NVDIMM-N).

Wait a sec...  In which places do you need sfence in all that?  movnt*
itself can be reordered, right?  So using that for copying and storing
the pointer afterwards would still need sfence inbetween, unless I'm
seriously misunderstanding the situation...

> Newly written data becomes globally visible before it becomes ADR-safe.
> This means software could act on the new data before a power loss, then
> see the old data reappear after the power loss - not good.  Software
> needs to understand that any data in the process of being written is
> indeterminate until the persistence guarantee is met.  The BTT shows
> one way that software can avoid that problem.

Joy.  What happens in terms of latency?  I.e. how much of a stall does
clwb inflict?

Re: [PATCH] drivers: misc: mic: constify mbus_hw_ops structures

[Vinod Koul]

On Tue, Dec 20, 2016 at 04:26:17PM +0530, Bhumika Goyal wrote:
> The fields of structure mbus_hw_ops are never modified after
> initialization, so declare these structures as const. Add a const
> annotation to all its initializations and uses like function arguments
> and pointers.
> Used Coccinelle to find all the occurences.

Can you please split these per driver so that they can be merged thru their
own subsystems.


-- 
~Vinod

Re: [PATCH] Wrong domain name in the email address

[Vinod Koul]

On Tue, Dec 20, 2016 at 07:07:35PM +0530, Amit Kumar wrote:
> cudeaurora.org is used in place of codeaurora.org
> in the contact field.

Please ensure you use right subsystem tags.
applied after fixing that

-- 
~Vinod

Re: [PATCH] mm: cma: print allocation failure reason and bitmap status

[Jaewon Kim]

On 2017년 01월 02일 06:59, Michal Nazarewicz wrote:
> On Fri, Dec 30 2016, Michal Hocko wrote:
>> On Fri 30-12-16 16:24:46, Jaewon Kim wrote:
>> [...]
>>> >From 7577cc94da3af27907aa6eec590d2ef51e4b9d80 Mon Sep 17 00:00:00 2001
>>> From: Jaewon Kim 
>>> Date: Thu, 29 Dec 2016 11:00:16 +0900
>>> Subject: [PATCH] mm: cma: print allocation failure reason and bitmap status
>>>
>>> There are many reasons of CMA allocation failure such as EBUSY, ENOMEM, 
>>> EINTR.
>>> But we did not know error reason so far. This patch prints the error value.
>>>
>>> Additionally if CONFIG_CMA_DEBUG is enabled, this patch shows bitmap status 
>>> to
>>> know available pages. Actually CMA internally try all available regions 
>>> because
>>> some regions can be failed because of EBUSY. Bitmap status is useful to 
>>> know in
>>> detail on both ENONEM and EBUSY;
>>>  ENOMEM: not tried at all because of no available region
>>>  it could be too small total region or could be fragmentation issue
>>>  EBUSY:  tried some region but all failed
>>>
>>> This is an ENOMEM example with this patch.
>>> [   13.250961]  [1:   Binder:715_1:  846] cma: cma_alloc: alloc failed, 
>>> req-size: 256 pages, ret: -12
>>> Avabile pages also will be shown if CONFIG_CMA_DEBUG is enabled
>>> [   13.251052]  [1:   Binder:715_1:  846] cma: number of available pages: 
>>> 4@572+7@585+7@601+8@632+38@730+166@1114+127@1921=>357 pages, total: 2048 
>>> pages
>> please mention how to interpret this information.
Thank you Michal Hocko. I added like this
If CONFIG_CMA_DEBUG is enabled, avabile pages also will be shown as concatenated
size@position format. So 4@572 means that there are 4 available pages at 572
position starting from 0 position.
>>
>> some more style suggestions below
>>> Signed-off-by: Jaewon Kim 
> Acked-by: Michal Nazarewicz 
Thank you I added your Ack
Acked-by: Michal Nazarewicz 
>>> ---
>>>  mm/cma.c | 29 -
>>>  1 file changed, 28 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/mm/cma.c b/mm/cma.c
>>> index c960459..1bcd9db 100644
>>> --- a/mm/cma.c
>>> +++ b/mm/cma.c
>>> @@ -369,7 +369,7 @@ struct page *cma_alloc(struct cma *cma, size_t count, 
>>> unsigned int align)
>>>  unsigned long start = 0;
>>>  unsigned long bitmap_maxno, bitmap_no, bitmap_count;
>>>  struct page *page = NULL;
>>> -int ret;
>>> +int ret = -ENOMEM;
>>>  
>>>  if (!cma || !cma->count)
>>>  return NULL;
>>> @@ -427,6 +427,33 @@ struct page *cma_alloc(struct cma *cma, size_t count, 
>>> unsigned int align)
>>>  trace_cma_alloc(pfn, page, count, align);
>>>  
>>>  pr_debug("%s(): returned %p\n", __func__, page);
> This line should be moved after the ‘if (ret != 0)’ block, i.e. just
> before return.
Thank you Michal Nazarewicz
I moved the pr_debug right before return
 pr_debug("%s(): returned %p\n", __func__, page);
 return page;
>>> +
>>> +if (ret != 0)
>> you can simply do
>>  if (!ret) {
Thank you
I changed like this, it should be if(ret) rather than if(!ret)
+if (ret) {
+pr_info("%s: alloc failed, req-size: %zu pages, ret: %d\n",
+__func__, count, ret);
+debug_show_cma_areas(cma);
+}
>>
>>  pr_info("%s: alloc failed, req-size: %zu pages, ret: %d\n",
>>  __func__, count, ret);
>>  debug_show_cma_areas();
>>  }
>>
>>  return page;
>>
>> static void debug_show_cma_areas(void)
>> {
>> #ifdef CONFIG_CMA_DEBUG
>>  unsigned int nr, nr_total = 0;
>>  unsigned long next_set_bit;
>>
>>  mutex_lock(&cma->lock);
>>  pr_info("number of available pages: ");
>>  start = 0;
>>  for (;;) {
>>  bitmap_no = find_next_zero_bit(cma->bitmap, cma->count, start);
>>  if (bitmap_no >= cma->count)
>>  break;
>>  next_set_bit = find_next_bit(cma->bitmap, cma->count, 
>> bitmap_no);
>>  nr = next_set_bit - bitmap_no;
>>  pr_cont("%s%u@%lu", nr_total ? "+" : "", nr, bitmap_no);
>>  nr_total += nr;
>>  start = bitmap_no + nr;
>>  }
>>  pr_cont("=>%u pages, total: %lu pages\n", nr_total, cma->count);
> Perhaps:
>   pr_cont("=> %u free of %lu total pages\n", nr_total, cma->count);
Thank you I will take this way.
+pr_cont("=> %u free of %lu total pages\n", nr_total, cma->count);
> or shorter (but more cryptic):
>   pr_cont("=> %u/%lu pages\n", nr_total, cma->count);
>
>>  mutex_unlock(&cma->lock);
>> #endif
>> }
> Actually, Linux style is more like:
>
> #ifdef CONFIG_CMA_DEBUG
> static void cma_debug_show_areas()
> {
>   …
> }
> #else
> static inline void cma_debug_show_areas() { }
> #endif
Thank you I will take this way. FYI struct cma address should be passed as a 
argument.
+#ifdef CONFIG_CMA_DEBUG
+static void debug_show_cma_areas(struct cma *cma)
+{
...
+#else
+static inline void debug_show_cma_areas(struct cma *cma) { }
+#endif
>> -- 
>> Michal Hocko
>> SUSE Labs

Thank you a

Re: [PATCH] taint/module: Fix problems when out-of-kernel driver defines true or false

[Christoph Hellwig]

On Sun, Jan 01, 2017 at 08:25:25PM -0600, Larry Finger wrote:
> Commit 7fd8329ba502 ("taint/module: Clean up global and module taint
> flags handling") used the key words true and false as character members
> of a new struct. These names cause problems when out-of-kernel modules
> such as VirtualBox include their own definitions of true and false.

Whuch they should not define, so fix them, just like you;d fix them for
everything else that would conflict with something in kernel headers.

[REGRESSION] Kernel panic in firmware_request since v4.9

[Ben Gamari]

Hello everyone,

After a recent upgrade to 4.10-rc2 I noticed that my wireless adapter
didn't come up due to a kernel panic in the firmware class induced by
iwlwifi,

BUG: unable to handle kernel NULL pointer dereference at 0038
IP: _request_firmware+0x995/0xa40
PGD 0 

Oops:  [#1] SMP
Modules linked in: i915(+) joydev rtsx_pci_sdmmc irqbypass crct10dif_pclmul 
crc32_pclmul ghash_clmulni_intel pcbc iTCO_wdt iTCO_vendor_support uvcvideo 
dell_smm_hwmon aesni_intel aes_x86_64 crypto_simd videobuf2_vmalloc glue_helper 
videobuf2_memops cryptd videobuf2_v4l2 videobuf2_core snd_hda_intel videodev 
coretemp snd_hda_codec tg3 snd_hda_core iwlwifi pcspkr hid_multitouch psmouse 
drm_kms_helper snd_hwdep drm snd_pcm snd_timer rtsx_pci snd cfg80211 
i2c_algo_bit mei_me soundcore fb_sys_fops mei syscopyarea i2c_i801 sysfillrect 
sg sysimgblt shpchp hci_uart wmi acpi_als video intel_lpss_acpi kfifo_buf 
intel_lpss industrialio i2c_hid acpi_pad e1000e ptp pps_core e1000 sunrpc 
parport_pc ppdev lp parport ip_tables x_tables autofs4 raid10 raid456 libcrc32c 
async_raid6_recov async_memcpy async_pq
async_xor xor async_tx btusb btrtl btbcm btintel bluetooth raid6_pq raid1 
raid0 multipath linear hid_generic usbkbd usbhid hid ahci serio_raw libahci 
pinctrl_sunrisepoint pinctrl_intel
CPU: 0 PID: 321 Comm: kworker/0:2 Not tainted 4.9.0+ #4
Hardware name: Dell Inc. Latitude E7470/0T6HHJ, BIOS 1.6.3 06/15/2016
Workqueue: events request_firmware_work_func
task: 88082420 task.stack: c90003a94000
RIP: 0010:_request_firmware+0x995/0xa40
RSP: :c90003a97db8 EFLAGS: 00010246
RAX: fffe RBX: 88082441b000 RCX: 88082441b028
RDX: 88082420 RSI: 0287 RDI: 
RBP: c90003a97e30 R08: 88084cc104e0 R09: 
R10: 00017a1c7c3f R11: 7f894759ed80 R12: c90003a97e40
R13: 0007 R14: 88081c4a4800 R15: 3a98
FS:  () GS:88084cc0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0038 CR3: 000824ef3000 CR4: 003406f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
request_firmware_work_func+0x2b/0x60
process_one_work+0x1fc/0x490
worker_thread+0x4b/0x500
kthread+0x101/0x140
? process_one_work+0x490/0x490
? kthread_create_on_node+0x40/0x40
? do_syscall_64+0x6e/0x180
ret_from_fork+0x25/0x30
Code: 9e d0 81 e8 4e 6d fe ff b8 f4 ff ff ff e9 db f9 ff ff 48 c7 c7 60 91 
ed 81 89 45 b0 e8 95 a3 29 00 49 8b be 00 03 00 00 8b 45 b0 <83> 7f 38 02 74 08 
e8 40 eb ff ff 8b 45 b0 49 c7 86 00 03 00 00 
RIP: _request_firmware+0x995/0xa40 RSP: c90003a97db8
CR2: 0038
---[ end trace 94dd071852e99747 ]---

This occurs while iwlwifi is trying to load a firmware image that
(expectedly) does not exist on my system. In prior kernel versions this
would fail with,

iwlwifi :01:00.0: Direct firmware load for iwlwifi-8000C-26.ucode 
failed with error -2
iwlwifi :01:00.0: Falling back to user helper

and continue to load other images until it found an available version
(-22.ucode). Note that this is a Debian Sid system running systemd 232.
I believe this failure is also reproducible in the 4.9 kernel.

A bit of digging revealed that the non-existent firmware image triggers
an unchecked dereference of buf->fw_st in __fw_load_abort. The attached
patch avoids the issue although it's unclear whether this is the correct
fix. It appears there have been a few refactorings in
driver/base/firmware_class.c recently. I've CC'd the authors of these
patches in hopes that this will ring a bell with someone.

Cheers,

- Ben



diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 4497d263209f..badc5737bad2 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -546,7 +546,8 @@ static void __fw_load_abort(struct firmware_buf *buf)
 * There is a small window in which user can write to 'loading'
 * between loading done and disappearance of 'loading'
 */
-   if (fw_state_is_done(&buf->fw_st))
+   if (!buf || fw_state_is_done(&buf->fw_st))
return;
 
list_del_init(&buf->pending_list);
-- 
2.11.0



signature.asc
Description: PGP signature

Re: [PATCH V2] Xen: ARM: Zero reserved fields of xatp before making hypervisor call

[Juergen Gross]

On 28/12/16 01:47, Jiandi An wrote:
> Ensure all reserved fields of xatp are zero before making
> hypervisor call to XEN in xen_map_device_mmio().
> xenmem_add_to_physmap_one() in XEN fails the mapping request if
> extra.res reserved field in xatp is not zero for XENMAPSPACE_dev_mmio
> request.
> 
> Signed-off-by: Jiandi An 
> ---
> Changed zeroing xatp to a static initialization
> of .domid and .space for xatp.
> 
>  drivers/xen/arm-device.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/xen/arm-device.c b/drivers/xen/arm-device.c
> index 778acf8..85dd20e 100644
> --- a/drivers/xen/arm-device.c
> +++ b/drivers/xen/arm-device.c
> @@ -58,9 +58,13 @@ static int xen_map_device_mmio(const struct resource 
> *resources,
>   xen_pfn_t *gpfns;
>   xen_ulong_t *idxs;
>   int *errs;
> - struct xen_add_to_physmap_range xatp;
>  
>   for (i = 0; i < count; i++) {
> + struct xen_add_to_physmap_range xatp = {
> + .domid = DOMID_SELF,
> + .space = XENMAPSPACE_dev_mmio
> + };
> +

I still don't see the need to re-initialize the input parts of xatp
on each loop iteration unless you can show the need for it (e.g. a
buggy hypervisor version not conforming to the interface specification).

OTOH I don't feel really strong about it and let Stefano being the
maintainer for the ARM parts decide.


Juergen

>   r = &resources[i];
>   nr = DIV_ROUND_UP(resource_size(r), XEN_PAGE_SIZE);
>   if ((resource_type(r) != IORESOURCE_MEM) || (nr == 0))
> @@ -87,9 +91,7 @@ static int xen_map_device_mmio(const struct resource 
> *resources,
>   idxs[j] = XEN_PFN_DOWN(r->start) + j;
>   }
>  
> - xatp.domid = DOMID_SELF;
>   xatp.size = nr;
> - xatp.space = XENMAPSPACE_dev_mmio;
>  
>   set_xen_guest_handle(xatp.gpfns, gpfns);
>   set_xen_guest_handle(xatp.idxs, idxs);
> 

Re: [PATCH 1/2] arm64:dt:ls1046a: Add TMU device tree support for LS1046A

[Shawn Guo]

On Thu, Dec 08, 2016 at 11:28:25AM +0800, Jia Hongtao wrote:
> Also add nodes and properties for thermal management support.
> 
> Signed-off-by: Jia Hongtao 

"arm64: dts: ls1046a: ..." for subject prefix please.  Also, since we
have ls1046a in prefix, the 'for LS1046A' is not needed.

> ---
>  arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 79 
> ++
>  1 file changed, 79 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi 
> b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> index 38806ca..40604e9 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> @@ -45,6 +45,8 @@
>   */
>  
>  #include 
> +#include 
> +

Unneeded newline.

>  
>  / {
>   compatible = "fsl,ls1046a";
> @@ -67,6 +69,7 @@
>   clocks = <&clockgen 1 0>;
>   next-level-cache = <&l2>;
>   cpu-idle-states = <&CPU_PH20>;
> + #cooling-cells = <2>;
>   };
>  
>   cpu1: cpu@1 {
> @@ -279,6 +282,82 @@
>   clocks = <&sysclk>;
>   };
>  
> + tmu: tmu@1f0 {
> + compatible = "fsl,qoriq-tmu";
> + reg = <0x0 0x1f0 0x0 0x1>;
> + interrupts = <0 33 0x4>;
> + fsl,tmu-range = <0xb 0x9002a 0x6004c 0x30062>;
> + fsl,tmu-calibration = <0x 0x0026
> +0x0001 0x002d
> +0x0002 0x0032
> +0x0003 0x0039
> +0x0004 0x003f
> +0x0005 0x0046
> +0x0006 0x004d
> +0x0007 0x0054
> +0x0008 0x005a
> +0x0009 0x0061
> +0x000a 0x006a
> +0x000b 0x0071
> +

Instead of a newline, can we have a single line comment here to tell how
these calibration data is grouped?

> +0x0001 0x0025
> +0x00010001 0x002c
> +0x00010002 0x0035
> +0x00010003 0x003d
> +0x00010004 0x0045
> +0x00010005 0x004e
> +0x00010006 0x0057
> +0x00010007 0x0061
> +0x00010008 0x006b
> +0x00010009 0x0076
> +
> +0x0002 0x0029
> +0x00020001 0x0033
> +0x00020002 0x003d
> +0x00020003 0x0049
> +0x00020004 0x0056
> +0x00020005 0x0061
> +0x00020006 0x006d
> +
> +0x0003 0x0021
> +0x00030001 0x002a
> +0x00030002 0x003c
> +0x00030003 0x004e>;
> + big-endian;
> + #thermal-sensor-cells = <1>;
> + };
> +
> + thermal-zones {
> + cpu_thermal: cpu-thermal {
> + polling-delay-passive = <1000>;
> + polling-delay = <5000>;
> +

We usually do not have newline between properties but nodes, or between
property list and child node.

> + thermal-sensors = <&tmu 3>;
> +
> + trips {
> + cpu_alert: cpu-alert {
> + temperature = <85000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };

Have a newline here.

Shawn

> + cpu_crit: cpu-crit {
> + temperature = <95000>;
> + hysteresis = <2000>;
> + type = "critical";
> + 

surface3_button.c:undefined reference to `i2c_del_driver'

[kbuild test robot]

Hi Benjamin,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   0c744ea4f77d72b3dcebb7a8f2684633ec79be88
commit: 1a64b719d3ae0e4fb939d9a9e31abb60b4ce4eb1 platform/x86: Introduce button 
support for the Surface 3
date:   2 weeks ago
config: i386-randconfig-c0-01021248 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout 1a64b719d3ae0e4fb939d9a9e31abb60b4ce4eb1
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `surface3_driver_exit':
>> surface3_button.c:(.exit.text+0x152d): undefined reference to 
>> `i2c_del_driver'
   drivers/built-in.o: In function `surface3_driver_init':
>> surface3_button.c:(.init.text+0x1754d): undefined reference to 
>> `i2c_register_driver'

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


.config.gz
Description: application/gzip

Re: [PATCH 2/2] arm64:dt:ls1012a: Add TMU device tree support for LS1012A

[Shawn Guo]

On Thu, Dec 08, 2016 at 11:28:26AM +0800, Jia Hongtao wrote:
> Also add nodes and properties for thermal management support.
> 
> Signed-off-by: Jia Hongtao 
> ---
> Depend on patch "[v3] arm64: Add DTS support for FSL's LS1012A SoC".
> https://patchwork.kernel.org/patch/9462399/

Please send me the patch only after the dependent one is already
accepted.

Shawn