Re: [PATCH v6 1/2] tcmu: Add dynamic growing data area feature support

[Mike Christie]

On 04/26/2017 01:25 AM, lixi...@cmss.chinamobile.com wrote:
>   for_each_sg(data_sg, sg, data_nents, i) {
> @@ -275,22 +371,26 @@ static void alloc_and_scatter_data_area(struct tcmu_dev 
> *udev,
>   from = kmap_atomic(sg_page(sg)) + sg->offset;
>   while (sg_remaining > 0) {
>   if (block_remaining == 0) {
> - block = find_first_zero_bit(udev->data_bitmap,
> - DATA_BLOCK_BITS);
>   block_remaining = DATA_BLOCK_SIZE;
> - set_bit(block, udev->data_bitmap);
> + dbi = tcmu_get_empty_block(udev, );
> + if (dbi < 0)


I know it you fixed the missing kunmap_atomic here and missing unlock in
tcmu_queue_cmd_ring in the next patch, but I think normally people
prefer that one patch does not add a bug, then the next patch fixes it.

Re: [PATCH v6 1/2] tcmu: Add dynamic growing data area feature support

[Mike Christie]

On 04/26/2017 01:25 AM, lixi...@cmss.chinamobile.com wrote:
>   for_each_sg(data_sg, sg, data_nents, i) {
> @@ -275,22 +371,26 @@ static void alloc_and_scatter_data_area(struct tcmu_dev 
> *udev,
>   from = kmap_atomic(sg_page(sg)) + sg->offset;
>   while (sg_remaining > 0) {
>   if (block_remaining == 0) {
> - block = find_first_zero_bit(udev->data_bitmap,
> - DATA_BLOCK_BITS);
>   block_remaining = DATA_BLOCK_SIZE;
> - set_bit(block, udev->data_bitmap);
> + dbi = tcmu_get_empty_block(udev, );
> + if (dbi < 0)


I know it you fixed the missing kunmap_atomic here and missing unlock in
tcmu_queue_cmd_ring in the next patch, but I think normally people
prefer that one patch does not add a bug, then the next patch fixes it.

[PATCH] net: phy: Allow BCM5481x PHYs to setup internal TX/RX clock delay

[Abhishek Shah]

This patch allows users to enable/disable internal TX and/or RX
clock delay for BCM5481x series PHYs so as to satisfy RGMII timing
specifications.

On a particular platform, whether TX and/or RX clock delay is required
depends on how PHY connected to the MAC IP. This requirement can be
specified through "phy-mode" property in the platform device tree.

Signed-off-by: Abhishek Shah 
---
 drivers/net/phy/broadcom.c | 69 ++
 1 file changed, 33 insertions(+), 36 deletions(-)

diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index 9cd8b27..a32dc5d 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -74,27 +74,40 @@ static int bcm54612e_config_init(struct phy_device *phydev)
return 0;
 }
 
-static int bcm54810_config(struct phy_device *phydev)
+static int bcm5481x_config(struct phy_device *phydev)
 {
int rc, val;
 
-   val = bcm_phy_read_exp(phydev, BCM54810_EXP_BROADREACH_LRE_MISC_CTL);
-   val &= ~BCM54810_EXP_BROADREACH_LRE_MISC_CTL_EN;
-   rc = bcm_phy_write_exp(phydev, BCM54810_EXP_BROADREACH_LRE_MISC_CTL,
-  val);
-   if (rc < 0)
-   return rc;
-
+   /* handling PHY's internal RX clock delay */
val = bcm54xx_auxctl_read(phydev, MII_BCM54XX_AUXCTL_SHDWSEL_MISC);
-   val &= ~MII_BCM54XX_AUXCTL_SHDWSEL_MISC_RGMII_SKEW_EN;
val |= MII_BCM54XX_AUXCTL_MISC_WREN;
+   if (phydev->interface == PHY_INTERFACE_MODE_RGMII ||
+   phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID) {
+   /* Disable RGMII RXC-RXD skew */
+   val &= ~MII_BCM54XX_AUXCTL_SHDWSEL_MISC_RGMII_SKEW_EN;
+   }
+   if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
+   phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) {
+   /* Enable RGMII RXC-RXD skew */
+   val |= MII_BCM54XX_AUXCTL_SHDWSEL_MISC_RGMII_SKEW_EN;
+   }
rc = bcm54xx_auxctl_write(phydev, MII_BCM54XX_AUXCTL_SHDWSEL_MISC,
  val);
if (rc < 0)
return rc;
 
+   /* handling PHY's internal TX clock delay */
val = bcm_phy_read_shadow(phydev, BCM54810_SHD_CLK_CTL);
-   val &= ~BCM54810_SHD_CLK_CTL_GTXCLK_EN;
+   if (phydev->interface == PHY_INTERFACE_MODE_RGMII ||
+   phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) {
+   /* Disable internal TX clock delay */
+   val &= ~BCM54810_SHD_CLK_CTL_GTXCLK_EN;
+   }
+   if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
+   phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID) {
+   /* Enable internal TX clock delay */
+   val |= BCM54810_SHD_CLK_CTL_GTXCLK_EN;
+   }
rc = bcm_phy_write_shadow(phydev, BCM54810_SHD_CLK_CTL, val);
if (rc < 0)
return rc;
@@ -244,7 +257,7 @@ static void bcm54xx_adjust_rxrefclk(struct phy_device 
*phydev)
 
 static int bcm54xx_config_init(struct phy_device *phydev)
 {
-   int reg, err;
+   int reg, err, val;
 
reg = phy_read(phydev, MII_BCM54XX_ECR);
if (reg < 0)
@@ -283,8 +296,14 @@ static int bcm54xx_config_init(struct phy_device *phydev)
if (err)
return err;
} else if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54810) {
-   err = bcm54810_config(phydev);
-   if (err)
+   /* For BCM54810, we need to disable BroadR-Reach function */
+   val = bcm_phy_read_exp(phydev,
+  BCM54810_EXP_BROADREACH_LRE_MISC_CTL);
+   val &= ~BCM54810_EXP_BROADREACH_LRE_MISC_CTL_EN;
+   err = bcm_phy_write_exp(phydev,
+   BCM54810_EXP_BROADREACH_LRE_MISC_CTL,
+   val);
+   if (err < 0)
return err;
}
 
@@ -392,29 +411,7 @@ static int bcm5481_config_aneg(struct phy_device *phydev)
ret = genphy_config_aneg(phydev);
 
/* Then we can set up the delay. */
-   if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) {
-   u16 reg;
-
-   /*
-* There is no BCM5481 specification available, so down
-* here is everything we know about "register 0x18". This
-* at least helps BCM5481 to successfully receive packets
-* on MPC8360E-RDK board. Peter Barada 
-* says: "This sets delay between the RXD and RXC signals
-* instead of using trace lengths to achieve timing".
-*/
-
-   /* Set RDX clk delay. */
-   reg = 0x7 | (0x7 << 12);
-   phy_write(phydev, 0x18, reg);
-
-   reg = phy_read(phydev, 0x18);
-   /* Set RDX-RXC skew. */
-   reg |= (1 << 8);
-  

[PATCH] net: phy: Allow BCM5481x PHYs to setup internal TX/RX clock delay

[Abhishek Shah]

This patch allows users to enable/disable internal TX and/or RX
clock delay for BCM5481x series PHYs so as to satisfy RGMII timing
specifications.

On a particular platform, whether TX and/or RX clock delay is required
depends on how PHY connected to the MAC IP. This requirement can be
specified through "phy-mode" property in the platform device tree.

Signed-off-by: Abhishek Shah 
---
 drivers/net/phy/broadcom.c | 69 ++
 1 file changed, 33 insertions(+), 36 deletions(-)

diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index 9cd8b27..a32dc5d 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -74,27 +74,40 @@ static int bcm54612e_config_init(struct phy_device *phydev)
return 0;
 }
 
-static int bcm54810_config(struct phy_device *phydev)
+static int bcm5481x_config(struct phy_device *phydev)
 {
int rc, val;
 
-   val = bcm_phy_read_exp(phydev, BCM54810_EXP_BROADREACH_LRE_MISC_CTL);
-   val &= ~BCM54810_EXP_BROADREACH_LRE_MISC_CTL_EN;
-   rc = bcm_phy_write_exp(phydev, BCM54810_EXP_BROADREACH_LRE_MISC_CTL,
-  val);
-   if (rc < 0)
-   return rc;
-
+   /* handling PHY's internal RX clock delay */
val = bcm54xx_auxctl_read(phydev, MII_BCM54XX_AUXCTL_SHDWSEL_MISC);
-   val &= ~MII_BCM54XX_AUXCTL_SHDWSEL_MISC_RGMII_SKEW_EN;
val |= MII_BCM54XX_AUXCTL_MISC_WREN;
+   if (phydev->interface == PHY_INTERFACE_MODE_RGMII ||
+   phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID) {
+   /* Disable RGMII RXC-RXD skew */
+   val &= ~MII_BCM54XX_AUXCTL_SHDWSEL_MISC_RGMII_SKEW_EN;
+   }
+   if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
+   phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) {
+   /* Enable RGMII RXC-RXD skew */
+   val |= MII_BCM54XX_AUXCTL_SHDWSEL_MISC_RGMII_SKEW_EN;
+   }
rc = bcm54xx_auxctl_write(phydev, MII_BCM54XX_AUXCTL_SHDWSEL_MISC,
  val);
if (rc < 0)
return rc;
 
+   /* handling PHY's internal TX clock delay */
val = bcm_phy_read_shadow(phydev, BCM54810_SHD_CLK_CTL);
-   val &= ~BCM54810_SHD_CLK_CTL_GTXCLK_EN;
+   if (phydev->interface == PHY_INTERFACE_MODE_RGMII ||
+   phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) {
+   /* Disable internal TX clock delay */
+   val &= ~BCM54810_SHD_CLK_CTL_GTXCLK_EN;
+   }
+   if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
+   phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID) {
+   /* Enable internal TX clock delay */
+   val |= BCM54810_SHD_CLK_CTL_GTXCLK_EN;
+   }
rc = bcm_phy_write_shadow(phydev, BCM54810_SHD_CLK_CTL, val);
if (rc < 0)
return rc;
@@ -244,7 +257,7 @@ static void bcm54xx_adjust_rxrefclk(struct phy_device 
*phydev)
 
 static int bcm54xx_config_init(struct phy_device *phydev)
 {
-   int reg, err;
+   int reg, err, val;
 
reg = phy_read(phydev, MII_BCM54XX_ECR);
if (reg < 0)
@@ -283,8 +296,14 @@ static int bcm54xx_config_init(struct phy_device *phydev)
if (err)
return err;
} else if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54810) {
-   err = bcm54810_config(phydev);
-   if (err)
+   /* For BCM54810, we need to disable BroadR-Reach function */
+   val = bcm_phy_read_exp(phydev,
+  BCM54810_EXP_BROADREACH_LRE_MISC_CTL);
+   val &= ~BCM54810_EXP_BROADREACH_LRE_MISC_CTL_EN;
+   err = bcm_phy_write_exp(phydev,
+   BCM54810_EXP_BROADREACH_LRE_MISC_CTL,
+   val);
+   if (err < 0)
return err;
}
 
@@ -392,29 +411,7 @@ static int bcm5481_config_aneg(struct phy_device *phydev)
ret = genphy_config_aneg(phydev);
 
/* Then we can set up the delay. */
-   if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) {
-   u16 reg;
-
-   /*
-* There is no BCM5481 specification available, so down
-* here is everything we know about "register 0x18". This
-* at least helps BCM5481 to successfully receive packets
-* on MPC8360E-RDK board. Peter Barada 
-* says: "This sets delay between the RXD and RXC signals
-* instead of using trace lengths to achieve timing".
-*/
-
-   /* Set RDX clk delay. */
-   reg = 0x7 | (0x7 << 12);
-   phy_write(phydev, 0x18, reg);
-
-   reg = phy_read(phydev, 0x18);
-   /* Set RDX-RXC skew. */
-   reg |= (1 << 8);
-   /* Write bits 14:0. */
-   

Re: Updating kernel.org cross compilers?

[Segher Boessenkool]

Hi,

On Wed, Apr 26, 2017 at 03:14:16PM +0100, Andre Przywara wrote:
> It seems that many people (even outside the Linux kernel community) use
> the cross compilers provided at kernel.org/pub/tools/crosstool.
> The latest compiler I find there is 4.9.0, which celebrated its third
> birthday at the weekend, also has been superseded by 4.9.4 meanwhile.
> 
> So I took Segher's buildall scripts from [1] and threw binutils 2.28 and
> GCC 6.3.0 at them.

Happy to see people are still using these!

> After removing --enable-sjlj-exceptions from build-gcc

This was needed to build some targets.  It does prevent aarch64 from
building without patch.

> and adding --disable-multilib (for building x86-64 on a x86-64
> box without 32-bit libs)

Why is this needed?  What error are you seeing.

> I was able to build (bare-metal) toolchains for
> all architectures except arc, m68k, tilegx and tilepro.

arc needs a more recent GCC; the other probably as well.  GCC 7 should
be out very soon, you probably want to wait for that :-)

> $ ./buildall --toolchain
> $ PATH=$PATH:/opt/cross/bin
> $ ./buildall --kernel

You should have the target dir in your PATH before doing anything else.
Is this not documented?  Hrm I guess not, let me fix that.

> And what is a good build setup, so that the binaries run on as many
> systems as possible?

Run contrib/download_prerequisites in the gcc source dir: this will
make GMP, MPFR, MPC statically linked, and use a version of each that
is known to work (and work correctly).

> [1] http://git.infradead.org/users/segher/buildall.git/

I'll push some changes that make aarch64 work out-of-the-box in a
minute.  It does some other things as well (e.g., make ia64 work again
after *that* change); more changes are still needed to make sh4 work
without patches.


Segher

Re: Updating kernel.org cross compilers?

[Segher Boessenkool]

Hi,

On Wed, Apr 26, 2017 at 03:14:16PM +0100, Andre Przywara wrote:
> It seems that many people (even outside the Linux kernel community) use
> the cross compilers provided at kernel.org/pub/tools/crosstool.
> The latest compiler I find there is 4.9.0, which celebrated its third
> birthday at the weekend, also has been superseded by 4.9.4 meanwhile.
> 
> So I took Segher's buildall scripts from [1] and threw binutils 2.28 and
> GCC 6.3.0 at them.

Happy to see people are still using these!

> After removing --enable-sjlj-exceptions from build-gcc

This was needed to build some targets.  It does prevent aarch64 from
building without patch.

> and adding --disable-multilib (for building x86-64 on a x86-64
> box without 32-bit libs)

Why is this needed?  What error are you seeing.

> I was able to build (bare-metal) toolchains for
> all architectures except arc, m68k, tilegx and tilepro.

arc needs a more recent GCC; the other probably as well.  GCC 7 should
be out very soon, you probably want to wait for that :-)

> $ ./buildall --toolchain
> $ PATH=$PATH:/opt/cross/bin
> $ ./buildall --kernel

You should have the target dir in your PATH before doing anything else.
Is this not documented?  Hrm I guess not, let me fix that.

> And what is a good build setup, so that the binaries run on as many
> systems as possible?

Run contrib/download_prerequisites in the gcc source dir: this will
make GMP, MPFR, MPC statically linked, and use a version of each that
is known to work (and work correctly).

> [1] http://git.infradead.org/users/segher/buildall.git/

I'll push some changes that make aarch64 work out-of-the-box in a
minute.  It does some other things as well (e.g., make ia64 work again
after *that* change); more changes are still needed to make sh4 work
without patches.


Segher

Re: Linux 4.4.65

[Greg KH]

diff --git a/Documentation/sysctl/fs.txt b/Documentation/sysctl/fs.txt
index 302b5ed616a6..35e17f748ca7 100644
--- a/Documentation/sysctl/fs.txt
+++ b/Documentation/sysctl/fs.txt
@@ -265,6 +265,13 @@ aio-nr can grow to.
 
 ==
 
+mount-max:
+
+This denotes the maximum number of mounts that may exist
+in a mount namespace.
+
+==
+
 
 2. /proc/sys/fs/binfmt_misc
 --
diff --git a/Makefile b/Makefile
index 17708f5dc169..ddaef04f528a 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 4
-SUBLEVEL = 64
+SUBLEVEL = 65
 EXTRAVERSION =
 NAME = Blurry Fish Butt
 
diff --git a/drivers/media/tuners/tuner-xc2028.c 
b/drivers/media/tuners/tuner-xc2028.c
index 4e941f00b600..082ff5608455 100644
--- a/drivers/media/tuners/tuner-xc2028.c
+++ b/drivers/media/tuners/tuner-xc2028.c
@@ -1403,11 +1403,12 @@ static int xc2028_set_config(struct dvb_frontend *fe, 
void *priv_cfg)
 * in order to avoid troubles during device release.
 */
kfree(priv->ctrl.fname);
+   priv->ctrl.fname = NULL;
memcpy(>ctrl, p, sizeof(priv->ctrl));
if (p->fname) {
priv->ctrl.fname = kstrdup(p->fname, GFP_KERNEL);
if (priv->ctrl.fname == NULL)
-   rc = -ENOMEM;
+   return -ENOMEM;
}
 
/*
diff --git a/drivers/net/wireless/hostap/hostap_hw.c 
b/drivers/net/wireless/hostap/hostap_hw.c
index 6df3ee561d52..515aa3f993f3 100644
--- a/drivers/net/wireless/hostap/hostap_hw.c
+++ b/drivers/net/wireless/hostap/hostap_hw.c
@@ -836,25 +836,30 @@ static int hfa384x_get_rid(struct net_device *dev, u16 
rid, void *buf, int len,
spin_lock_bh(>baplock);
 
res = hfa384x_setup_bap(dev, BAP0, rid, 0);
-   if (!res)
-   res = hfa384x_from_bap(dev, BAP0, , sizeof(rec));
+   if (res)
+   goto unlock;
+
+   res = hfa384x_from_bap(dev, BAP0, , sizeof(rec));
+   if (res)
+   goto unlock;
 
if (le16_to_cpu(rec.len) == 0) {
/* RID not available */
res = -ENODATA;
+   goto unlock;
}
 
rlen = (le16_to_cpu(rec.len) - 1) * 2;
-   if (!res && exact_len && rlen != len) {
+   if (exact_len && rlen != len) {
printk(KERN_DEBUG "%s: hfa384x_get_rid - RID len mismatch: "
   "rid=0x%04x, len=%d (expected %d)\n",
   dev->name, rid, rlen, len);
res = -ENODATA;
}
 
-   if (!res)
-   res = hfa384x_from_bap(dev, BAP0, buf, len);
+   res = hfa384x_from_bap(dev, BAP0, buf, len);
 
+unlock:
spin_unlock_bh(>baplock);
mutex_unlock(>rid_bap_mtx);
 
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index df560216d702..374f840f31a4 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -387,13 +387,22 @@ static void ion_handle_get(struct ion_handle *handle)
kref_get(>ref);
 }
 
-static int ion_handle_put(struct ion_handle *handle)
+static int ion_handle_put_nolock(struct ion_handle *handle)
+{
+   int ret;
+
+   ret = kref_put(>ref, ion_handle_destroy);
+
+   return ret;
+}
+
+int ion_handle_put(struct ion_handle *handle)
 {
struct ion_client *client = handle->client;
int ret;
 
mutex_lock(>lock);
-   ret = kref_put(>ref, ion_handle_destroy);
+   ret = ion_handle_put_nolock(handle);
mutex_unlock(>lock);
 
return ret;
@@ -417,20 +426,30 @@ static struct ion_handle *ion_handle_lookup(struct 
ion_client *client,
return ERR_PTR(-EINVAL);
 }
 
-static struct ion_handle *ion_handle_get_by_id(struct ion_client *client,
+static struct ion_handle *ion_handle_get_by_id_nolock(struct ion_client 
*client,
int id)
 {
struct ion_handle *handle;
 
-   mutex_lock(>lock);
handle = idr_find(>idr, id);
if (handle)
ion_handle_get(handle);
-   mutex_unlock(>lock);
 
return handle ? handle : ERR_PTR(-EINVAL);
 }
 
+struct ion_handle *ion_handle_get_by_id(struct ion_client *client,
+   int id)
+{
+   struct ion_handle *handle;
+
+   mutex_lock(>lock);
+   handle = ion_handle_get_by_id_nolock(client, id);
+   mutex_unlock(>lock);
+
+   return handle;
+}
+
 static bool ion_handle_validate(struct ion_client *client,
struct ion_handle *handle)
 {
@@ -532,22 +551,28 @@ struct ion_handle *ion_alloc(struct ion_client *client, 
size_t len,
 }
 EXPORT_SYMBOL(ion_alloc);
 
-void ion_free(struct ion_client *client, struct ion_handle *handle)
+static void ion_free_nolock(struct ion_client *client, struct ion_handle 

Re: Linux 4.4.65

[Greg KH]

diff --git a/Documentation/sysctl/fs.txt b/Documentation/sysctl/fs.txt
index 302b5ed616a6..35e17f748ca7 100644
--- a/Documentation/sysctl/fs.txt
+++ b/Documentation/sysctl/fs.txt
@@ -265,6 +265,13 @@ aio-nr can grow to.
 
 ==
 
+mount-max:
+
+This denotes the maximum number of mounts that may exist
+in a mount namespace.
+
+==
+
 
 2. /proc/sys/fs/binfmt_misc
 --
diff --git a/Makefile b/Makefile
index 17708f5dc169..ddaef04f528a 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 4
-SUBLEVEL = 64
+SUBLEVEL = 65
 EXTRAVERSION =
 NAME = Blurry Fish Butt
 
diff --git a/drivers/media/tuners/tuner-xc2028.c 
b/drivers/media/tuners/tuner-xc2028.c
index 4e941f00b600..082ff5608455 100644
--- a/drivers/media/tuners/tuner-xc2028.c
+++ b/drivers/media/tuners/tuner-xc2028.c
@@ -1403,11 +1403,12 @@ static int xc2028_set_config(struct dvb_frontend *fe, 
void *priv_cfg)
 * in order to avoid troubles during device release.
 */
kfree(priv->ctrl.fname);
+   priv->ctrl.fname = NULL;
memcpy(>ctrl, p, sizeof(priv->ctrl));
if (p->fname) {
priv->ctrl.fname = kstrdup(p->fname, GFP_KERNEL);
if (priv->ctrl.fname == NULL)
-   rc = -ENOMEM;
+   return -ENOMEM;
}
 
/*
diff --git a/drivers/net/wireless/hostap/hostap_hw.c 
b/drivers/net/wireless/hostap/hostap_hw.c
index 6df3ee561d52..515aa3f993f3 100644
--- a/drivers/net/wireless/hostap/hostap_hw.c
+++ b/drivers/net/wireless/hostap/hostap_hw.c
@@ -836,25 +836,30 @@ static int hfa384x_get_rid(struct net_device *dev, u16 
rid, void *buf, int len,
spin_lock_bh(>baplock);
 
res = hfa384x_setup_bap(dev, BAP0, rid, 0);
-   if (!res)
-   res = hfa384x_from_bap(dev, BAP0, , sizeof(rec));
+   if (res)
+   goto unlock;
+
+   res = hfa384x_from_bap(dev, BAP0, , sizeof(rec));
+   if (res)
+   goto unlock;
 
if (le16_to_cpu(rec.len) == 0) {
/* RID not available */
res = -ENODATA;
+   goto unlock;
}
 
rlen = (le16_to_cpu(rec.len) - 1) * 2;
-   if (!res && exact_len && rlen != len) {
+   if (exact_len && rlen != len) {
printk(KERN_DEBUG "%s: hfa384x_get_rid - RID len mismatch: "
   "rid=0x%04x, len=%d (expected %d)\n",
   dev->name, rid, rlen, len);
res = -ENODATA;
}
 
-   if (!res)
-   res = hfa384x_from_bap(dev, BAP0, buf, len);
+   res = hfa384x_from_bap(dev, BAP0, buf, len);
 
+unlock:
spin_unlock_bh(>baplock);
mutex_unlock(>rid_bap_mtx);
 
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index df560216d702..374f840f31a4 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -387,13 +387,22 @@ static void ion_handle_get(struct ion_handle *handle)
kref_get(>ref);
 }
 
-static int ion_handle_put(struct ion_handle *handle)
+static int ion_handle_put_nolock(struct ion_handle *handle)
+{
+   int ret;
+
+   ret = kref_put(>ref, ion_handle_destroy);
+
+   return ret;
+}
+
+int ion_handle_put(struct ion_handle *handle)
 {
struct ion_client *client = handle->client;
int ret;
 
mutex_lock(>lock);
-   ret = kref_put(>ref, ion_handle_destroy);
+   ret = ion_handle_put_nolock(handle);
mutex_unlock(>lock);
 
return ret;
@@ -417,20 +426,30 @@ static struct ion_handle *ion_handle_lookup(struct 
ion_client *client,
return ERR_PTR(-EINVAL);
 }
 
-static struct ion_handle *ion_handle_get_by_id(struct ion_client *client,
+static struct ion_handle *ion_handle_get_by_id_nolock(struct ion_client 
*client,
int id)
 {
struct ion_handle *handle;
 
-   mutex_lock(>lock);
handle = idr_find(>idr, id);
if (handle)
ion_handle_get(handle);
-   mutex_unlock(>lock);
 
return handle ? handle : ERR_PTR(-EINVAL);
 }
 
+struct ion_handle *ion_handle_get_by_id(struct ion_client *client,
+   int id)
+{
+   struct ion_handle *handle;
+
+   mutex_lock(>lock);
+   handle = ion_handle_get_by_id_nolock(client, id);
+   mutex_unlock(>lock);
+
+   return handle;
+}
+
 static bool ion_handle_validate(struct ion_client *client,
struct ion_handle *handle)
 {
@@ -532,22 +551,28 @@ struct ion_handle *ion_alloc(struct ion_client *client, 
size_t len,
 }
 EXPORT_SYMBOL(ion_alloc);
 
-void ion_free(struct ion_client *client, struct ion_handle *handle)
+static void ion_free_nolock(struct ion_client *client, struct ion_handle 

Linux 4.4.65

[Greg KH]

I'm announcing the release of the 4.4.65 kernel.

All users of the 4.4 kernel series must upgrade.

The updated 4.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.4.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Documentation/sysctl/fs.txt |7 +++
 Makefile|2 -
 drivers/media/tuners/tuner-xc2028.c |3 +
 drivers/net/wireless/hostap/hostap_hw.c |   15 +---
 drivers/staging/android/ion/ion.c   |   55 +++---
 drivers/tty/nozomi.c|2 -
 drivers/vfio/pci/vfio_pci.c |   33 +++---
 drivers/vfio/pci/vfio_pci_intrs.c   |2 -
 fs/gfs2/dir.c   |4 +-
 fs/mount.h  |2 +
 fs/namespace.c  |   50 +++-
 fs/pnode.c  |2 -
 fs/pnode.h  |1 
 include/linux/mount.h   |2 +
 kernel/events/core.c|   57 +---
 kernel/sysctl.c |9 +
 net/ipv4/ping.c |5 +-
 net/netfilter/nfnetlink.c   |   10 +++--
 net/tipc/bearer.c   |   13 ++-
 net/tipc/bearer.h   |   13 +++
 net/tipc/core.c |1 
 net/tipc/core.h |3 +
 net/tipc/name_distr.c   |   24 ++---
 net/tipc/node.c |4 +-
 net/tipc/socket.c   |   56 ---
 net/tipc/udp_media.c|7 +++
 26 files changed, 304 insertions(+), 78 deletions(-)

Arnd Bergmann (3):
  tty: nozomi: avoid a harmless gcc warning
  hostap: avoid uninitialized variable use in hfa384x_get_rid
  gfs2: avoid uninitialized variable warning

Eric Dumazet (1):
  ping: implement proper locking

Eric W. Biederman (1):
  mnt: Add a per mount namespace limit on the number of mounts

Erik Hugne (1):
  tipc: make dist queue pernet

EunTaik Lee (1):
  staging/android/ion : fix a race condition in the ion driver

Greg Kroah-Hartman (1):
  Linux 4.4.65

Jon Paul Maloy (3):
  tipc: re-enable compensation for socket receive buffer double counting
  tipc: correct error in node fsm
  tipc: fix socket timer deadlock

Mauro Carvalho Chehab (1):
  xc2028: avoid use after free

Michal Kubeček (1):
  tipc: check minimum bearer MTU

Parthasarathy Bhuvaragan (1):
  tipc: fix random link resets while adding a second bearer

Peter Zijlstra (1):
  perf/core: Fix concurrent sys_perf_event_open() vs. 'move_group' race

Phil Turnbull (1):
  netfilter: nfnetlink: correctly validate length of batch messages

Richard Alpe (1):
  tipc: make sure IPv6 header fits in skb headroom

Vlad Tsyrklevich (1):
  vfio/pci: Fix integer overflows, bitmask check



signature.asc
Description: PGP signature

Linux 4.4.65

[Greg KH]

I'm announcing the release of the 4.4.65 kernel.

All users of the 4.4 kernel series must upgrade.

The updated 4.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.4.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Documentation/sysctl/fs.txt |7 +++
 Makefile|2 -
 drivers/media/tuners/tuner-xc2028.c |3 +
 drivers/net/wireless/hostap/hostap_hw.c |   15 +---
 drivers/staging/android/ion/ion.c   |   55 +++---
 drivers/tty/nozomi.c|2 -
 drivers/vfio/pci/vfio_pci.c |   33 +++---
 drivers/vfio/pci/vfio_pci_intrs.c   |2 -
 fs/gfs2/dir.c   |4 +-
 fs/mount.h  |2 +
 fs/namespace.c  |   50 +++-
 fs/pnode.c  |2 -
 fs/pnode.h  |1 
 include/linux/mount.h   |2 +
 kernel/events/core.c|   57 +---
 kernel/sysctl.c |9 +
 net/ipv4/ping.c |5 +-
 net/netfilter/nfnetlink.c   |   10 +++--
 net/tipc/bearer.c   |   13 ++-
 net/tipc/bearer.h   |   13 +++
 net/tipc/core.c |1 
 net/tipc/core.h |3 +
 net/tipc/name_distr.c   |   24 ++---
 net/tipc/node.c |4 +-
 net/tipc/socket.c   |   56 ---
 net/tipc/udp_media.c|7 +++
 26 files changed, 304 insertions(+), 78 deletions(-)

Arnd Bergmann (3):
  tty: nozomi: avoid a harmless gcc warning
  hostap: avoid uninitialized variable use in hfa384x_get_rid
  gfs2: avoid uninitialized variable warning

Eric Dumazet (1):
  ping: implement proper locking

Eric W. Biederman (1):
  mnt: Add a per mount namespace limit on the number of mounts

Erik Hugne (1):
  tipc: make dist queue pernet

EunTaik Lee (1):
  staging/android/ion : fix a race condition in the ion driver

Greg Kroah-Hartman (1):
  Linux 4.4.65

Jon Paul Maloy (3):
  tipc: re-enable compensation for socket receive buffer double counting
  tipc: correct error in node fsm
  tipc: fix socket timer deadlock

Mauro Carvalho Chehab (1):
  xc2028: avoid use after free

Michal Kubeček (1):
  tipc: check minimum bearer MTU

Parthasarathy Bhuvaragan (1):
  tipc: fix random link resets while adding a second bearer

Peter Zijlstra (1):
  perf/core: Fix concurrent sys_perf_event_open() vs. 'move_group' race

Phil Turnbull (1):
  netfilter: nfnetlink: correctly validate length of batch messages

Richard Alpe (1):
  tipc: make sure IPv6 header fits in skb headroom

Vlad Tsyrklevich (1):
  vfio/pci: Fix integer overflows, bitmask check



signature.asc
Description: PGP signature

Linux 3.18.51

[Greg KH]

I'm announcing the release of the 3.18.51 kernel.

All users of the 3.18 kernel series must upgrade.

The updated 3.18.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.18.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile   |2 
 arch/arm/kernel/head-nommu.S   |   20 +--
 arch/arm/kvm/mmu.c |   12 ++
 arch/arm/mm/cache-l2x0.c   |  111 +++--
 arch/arm64/kernel/entry.S  |4 
 arch/arm64/kernel/traps.c  |   28 -
 arch/mips/include/asm/compiler.h   |   13 ++
 arch/mips/jz4740/board-qi_lb60.c   |1 
 arch/mips/jz4740/gpio.c|1 
 arch/mips/pci/ops-pmcmsp.c |   12 --
 arch/mips/ralink/prom.c|9 -
 arch/powerpc/kernel/entry_64.S |6 -
 arch/s390/include/asm/pgtable.h|2 
 arch/x86/configs/tiny.config   |2 
 arch/x86/kernel/cpu/mcheck/mce_amd.c   |2 
 drivers/acpi/power.c   |1 
 drivers/clk/at91/clk-usb.c |4 
 drivers/input/mouse/elantech.c |8 +
 drivers/iommu/intel-iommu.c|1 
 drivers/md/dm-bufio.c  |1 
 drivers/media/tuners/tuner-xc2028.c|3 
 drivers/misc/ioc4.c|   31 +++--
 drivers/mmc/host/sdhci-esdhc-imx.c |1 
 drivers/mmc/host/sunxi-mmc.c   |5 
 drivers/mtd/ubi/upd.c  |8 -
 drivers/net/ethernet/dec/tulip/tulip_core.c|9 +
 drivers/net/ethernet/dec/tulip/winbond-840.c   |2 
 drivers/net/ethernet/neterion/vxge/vxge-main.c |   31 ++---
 drivers/net/ethernet/ti/cpmac.c|5 
 drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c |2 
 drivers/net/wireless/hostap/hostap_hw.c|   15 +-
 drivers/scsi/aic94xx/aic94xx_sds.c |5 
 drivers/staging/android/ion/ion.c  |   55 +++---
 drivers/tty/nozomi.c   |2 
 drivers/usb/gadget/legacy/inode.c  |1 
 drivers/vfio/pci/vfio_pci.c|   33 +++---
 drivers/vfio/pci/vfio_pci_intrs.c  |2 
 fs/btrfs/extent_io.c   |2 
 fs/cifs/cifsglob.h |1 
 fs/cifs/netmisc.c  |   12 +-
 fs/cifs/smb1ops.c  |   10 +
 fs/cifs/smb2pdu.c  |5 
 fs/gfs2/dir.c  |4 
 fs/nfs/nfs4proc.c  |   11 --
 fs/nfsd/nfs4state.c|3 
 include/linux/ftrace_event.h   |2 
 include/linux/perf_event.h |   28 +++--
 include/trace/ftrace.h |7 -
 kernel/configs/tiny.config |8 +
 kernel/events/core.c   |   23 +++-
 kernel/sched/core.c|2 
 kernel/trace/ring_buffer.c |   16 ++-
 kernel/trace/trace.c   |8 -
 kernel/trace/trace_event_perf.c|4 
 kernel/trace/trace_kprobe.c|4 
 kernel/trace/trace_syscalls.c  |4 
 kernel/trace/trace_uprobe.c|2 
 mm/page_alloc.c|   17 +--
 net/ipv4/ping.c|5 
 security/keys/gc.c |2 
 security/keys/keyctl.c |   20 ++-
 security/keys/process_keys.c   |   44 +---
 62 files changed, 408 insertions(+), 286 deletions(-)

Alban Bedel (1):
  MIPS: Fix the build on jz4740 after removing the custom gpio.h

Alex Williamson (1):
  iommu/vt-d: Remove unused variable

Andre Przywara (1):
  fs/nfs: fix new compiler warning about boolean in switch

Arnd Bergmann (14):
  ACPI / power: Avoid maybe-uninitialized warning
  clk: at91: usb: fix determine_rate prototype again
  gadgetfs: fix uninitialized variable in error handling
  dm bufio: hide bogus warning
  nfsd: work around a gcc-5.1 warning
  brcmfmac: avoid gcc-5.1 warning
  tty: nozomi: avoid a harmless gcc warning
  net: vxge: avoid unused function warnings
  hostap: avoid uninitialized variable use in 

Re: Linux 3.18.51

[Greg KH]

diff --git a/Makefile b/Makefile
index 8665178e2a36..fb0d24411829 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 3
 PATCHLEVEL = 18
-SUBLEVEL = 50
+SUBLEVEL = 51
 EXTRAVERSION =
 NAME = Diseased Newt
 
diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
index cc176b67c134..c6c66dd4be89 100644
--- a/arch/arm/kernel/head-nommu.S
+++ b/arch/arm/kernel/head-nommu.S
@@ -77,13 +77,12 @@ ENTRY(stext)
orr r6, r6, #(1 << MPU_RSR_EN)  @ Set region enabled bit
bl  __setup_mpu
 #endif
-   ldr r13, =__mmap_switched   @ address to jump to after
-   @ initialising sctlr
adr lr, BSYM(1f)@ return (PIC) address
  ARM(  add pc, r10, #PROCINFO_INITFUNC )
  THUMB(add r12, r10, #PROCINFO_INITFUNC)
  THUMB(ret r12 )
- 1:b   __after_proc_init
+1: bl  __after_proc_init
+   b   __mmap_switched
 ENDPROC(stext)
 
 #ifdef CONFIG_SMP
@@ -106,8 +105,7 @@ ENTRY(secondary_startup)
movsr10, r5 @ invalid processor?
beq __error_p   @ yes, error 'p'
 
-   adr r4, __secondary_data
-   ldmia   r4, {r7, r12}
+   ldr r7, __secondary_data
 
 #ifdef CONFIG_ARM_MPU
/* Use MPU region info supplied by __cpu_up */
@@ -115,23 +113,19 @@ ENTRY(secondary_startup)
bl  __setup_mpu @ Initialize the MPU
 #endif
 
-   adr lr, BSYM(__after_proc_init) @ return address
-   mov r13, r12@ __secondary_switched address
+   adr lr, BSYM(1f)@ return (PIC) address
  ARM(  add pc, r10, #PROCINFO_INITFUNC )
  THUMB(add r12, r10, #PROCINFO_INITFUNC)
  THUMB(ret r12 )
-ENDPROC(secondary_startup)
-
-ENTRY(__secondary_switched)
+1: bl  __after_proc_init
ldr sp, [r7, #8]@ set up the stack pointer
mov fp, #0
b   secondary_start_kernel
-ENDPROC(__secondary_switched)
+ENDPROC(secondary_startup)
 
.type   __secondary_data, %object
 __secondary_data:
.long   secondary_data
-   .long   __secondary_switched
 #endif /* CONFIG_SMP */
 
 /*
@@ -164,7 +158,7 @@ __after_proc_init:
 #endif
mcr p15, 0, r0, c1, c0, 0   @ write control reg
 #endif /* CONFIG_CPU_CP15 */
-   ret r13
+   ret lr
 ENDPROC(__after_proc_init)
.ltorg
 
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 9fb14a37263b..3ffbce7277f7 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -256,6 +256,14 @@ static void unmap_range(struct kvm *kvm, pgd_t *pgdp,
next = kvm_pgd_addr_end(addr, end);
if (!pgd_none(*pgd))
unmap_puds(kvm, pgd, addr, next);
+   /*
+* If we are dealing with a large range in
+* stage2 table, release the kvm->mmu_lock
+* to prevent starvation and lockup detector
+* warnings.
+*/
+   if (kvm && (next != end))
+   cond_resched_lock(>mmu_lock);
} while (pgd++, addr = next, addr != end);
 }
 
@@ -693,6 +701,7 @@ int kvm_alloc_stage2_pgd(struct kvm *kvm)
  */
 static void unmap_stage2_range(struct kvm *kvm, phys_addr_t start, u64 size)
 {
+   assert_spin_locked(>mmu_lock);
unmap_range(kvm, kvm->arch.pgd, start, size);
 }
 
@@ -777,7 +786,10 @@ void kvm_free_stage2_pgd(struct kvm *kvm)
if (kvm->arch.pgd == NULL)
return;
 
+   spin_lock(>mmu_lock);
unmap_stage2_range(kvm, 0, KVM_PHYS_SIZE);
+   spin_unlock(>mmu_lock);
+
kvm_free_hwpgd(kvm_get_hwpgd(kvm));
if (KVM_PREALLOC_LEVEL > 0)
kfree(kvm->arch.pgd);
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 5e65ca8dea62..2d5ac8fb2d33 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -136,73 +136,6 @@ static void l2c_disable(void)
dsb(st);
 }
 
-#ifdef CONFIG_CACHE_PL310
-static inline void cache_wait(void __iomem *reg, unsigned long mask)
-{
-   /* cache operations by line are atomic on PL310 */
-}
-#else
-#define cache_wait l2c_wait_mask
-#endif
-
-static inline void cache_sync(void)
-{
-   void __iomem *base = l2x0_base;
-
-   writel_relaxed(0, base + sync_reg_offset);
-   cache_wait(base + L2X0_CACHE_SYNC, 1);
-}
-
-#if defined(CONFIG_PL310_ERRATA_588369) || defined(CONFIG_PL310_ERRATA_727915)
-static inline void debug_writel(unsigned long val)
-{
-   l2c_set_debug(l2x0_base, val);
-}
-#else
-/* Optimised out for non-errata case */
-static inline void debug_writel(unsigned long val)
-{
-}
-#endif
-
-static void l2x0_cache_sync(void)
-{
-   unsigned long flags;
-
-   

Linux 3.18.51

[Greg KH]

I'm announcing the release of the 3.18.51 kernel.

All users of the 3.18 kernel series must upgrade.

The updated 3.18.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.18.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile   |2 
 arch/arm/kernel/head-nommu.S   |   20 +--
 arch/arm/kvm/mmu.c |   12 ++
 arch/arm/mm/cache-l2x0.c   |  111 +++--
 arch/arm64/kernel/entry.S  |4 
 arch/arm64/kernel/traps.c  |   28 -
 arch/mips/include/asm/compiler.h   |   13 ++
 arch/mips/jz4740/board-qi_lb60.c   |1 
 arch/mips/jz4740/gpio.c|1 
 arch/mips/pci/ops-pmcmsp.c |   12 --
 arch/mips/ralink/prom.c|9 -
 arch/powerpc/kernel/entry_64.S |6 -
 arch/s390/include/asm/pgtable.h|2 
 arch/x86/configs/tiny.config   |2 
 arch/x86/kernel/cpu/mcheck/mce_amd.c   |2 
 drivers/acpi/power.c   |1 
 drivers/clk/at91/clk-usb.c |4 
 drivers/input/mouse/elantech.c |8 +
 drivers/iommu/intel-iommu.c|1 
 drivers/md/dm-bufio.c  |1 
 drivers/media/tuners/tuner-xc2028.c|3 
 drivers/misc/ioc4.c|   31 +++--
 drivers/mmc/host/sdhci-esdhc-imx.c |1 
 drivers/mmc/host/sunxi-mmc.c   |5 
 drivers/mtd/ubi/upd.c  |8 -
 drivers/net/ethernet/dec/tulip/tulip_core.c|9 +
 drivers/net/ethernet/dec/tulip/winbond-840.c   |2 
 drivers/net/ethernet/neterion/vxge/vxge-main.c |   31 ++---
 drivers/net/ethernet/ti/cpmac.c|5 
 drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c |2 
 drivers/net/wireless/hostap/hostap_hw.c|   15 +-
 drivers/scsi/aic94xx/aic94xx_sds.c |5 
 drivers/staging/android/ion/ion.c  |   55 +++---
 drivers/tty/nozomi.c   |2 
 drivers/usb/gadget/legacy/inode.c  |1 
 drivers/vfio/pci/vfio_pci.c|   33 +++---
 drivers/vfio/pci/vfio_pci_intrs.c  |2 
 fs/btrfs/extent_io.c   |2 
 fs/cifs/cifsglob.h |1 
 fs/cifs/netmisc.c  |   12 +-
 fs/cifs/smb1ops.c  |   10 +
 fs/cifs/smb2pdu.c  |5 
 fs/gfs2/dir.c  |4 
 fs/nfs/nfs4proc.c  |   11 --
 fs/nfsd/nfs4state.c|3 
 include/linux/ftrace_event.h   |2 
 include/linux/perf_event.h |   28 +++--
 include/trace/ftrace.h |7 -
 kernel/configs/tiny.config |8 +
 kernel/events/core.c   |   23 +++-
 kernel/sched/core.c|2 
 kernel/trace/ring_buffer.c |   16 ++-
 kernel/trace/trace.c   |8 -
 kernel/trace/trace_event_perf.c|4 
 kernel/trace/trace_kprobe.c|4 
 kernel/trace/trace_syscalls.c  |4 
 kernel/trace/trace_uprobe.c|2 
 mm/page_alloc.c|   17 +--
 net/ipv4/ping.c|5 
 security/keys/gc.c |2 
 security/keys/keyctl.c |   20 ++-
 security/keys/process_keys.c   |   44 +---
 62 files changed, 408 insertions(+), 286 deletions(-)

Alban Bedel (1):
  MIPS: Fix the build on jz4740 after removing the custom gpio.h

Alex Williamson (1):
  iommu/vt-d: Remove unused variable

Andre Przywara (1):
  fs/nfs: fix new compiler warning about boolean in switch

Arnd Bergmann (14):
  ACPI / power: Avoid maybe-uninitialized warning
  clk: at91: usb: fix determine_rate prototype again
  gadgetfs: fix uninitialized variable in error handling
  dm bufio: hide bogus warning
  nfsd: work around a gcc-5.1 warning
  brcmfmac: avoid gcc-5.1 warning
  tty: nozomi: avoid a harmless gcc warning
  net: vxge: avoid unused function warnings
  hostap: avoid uninitialized variable use in 

Re: Linux 3.18.51

[Greg KH]

diff --git a/Makefile b/Makefile
index 8665178e2a36..fb0d24411829 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 3
 PATCHLEVEL = 18
-SUBLEVEL = 50
+SUBLEVEL = 51
 EXTRAVERSION =
 NAME = Diseased Newt
 
diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
index cc176b67c134..c6c66dd4be89 100644
--- a/arch/arm/kernel/head-nommu.S
+++ b/arch/arm/kernel/head-nommu.S
@@ -77,13 +77,12 @@ ENTRY(stext)
orr r6, r6, #(1 << MPU_RSR_EN)  @ Set region enabled bit
bl  __setup_mpu
 #endif
-   ldr r13, =__mmap_switched   @ address to jump to after
-   @ initialising sctlr
adr lr, BSYM(1f)@ return (PIC) address
  ARM(  add pc, r10, #PROCINFO_INITFUNC )
  THUMB(add r12, r10, #PROCINFO_INITFUNC)
  THUMB(ret r12 )
- 1:b   __after_proc_init
+1: bl  __after_proc_init
+   b   __mmap_switched
 ENDPROC(stext)
 
 #ifdef CONFIG_SMP
@@ -106,8 +105,7 @@ ENTRY(secondary_startup)
movsr10, r5 @ invalid processor?
beq __error_p   @ yes, error 'p'
 
-   adr r4, __secondary_data
-   ldmia   r4, {r7, r12}
+   ldr r7, __secondary_data
 
 #ifdef CONFIG_ARM_MPU
/* Use MPU region info supplied by __cpu_up */
@@ -115,23 +113,19 @@ ENTRY(secondary_startup)
bl  __setup_mpu @ Initialize the MPU
 #endif
 
-   adr lr, BSYM(__after_proc_init) @ return address
-   mov r13, r12@ __secondary_switched address
+   adr lr, BSYM(1f)@ return (PIC) address
  ARM(  add pc, r10, #PROCINFO_INITFUNC )
  THUMB(add r12, r10, #PROCINFO_INITFUNC)
  THUMB(ret r12 )
-ENDPROC(secondary_startup)
-
-ENTRY(__secondary_switched)
+1: bl  __after_proc_init
ldr sp, [r7, #8]@ set up the stack pointer
mov fp, #0
b   secondary_start_kernel
-ENDPROC(__secondary_switched)
+ENDPROC(secondary_startup)
 
.type   __secondary_data, %object
 __secondary_data:
.long   secondary_data
-   .long   __secondary_switched
 #endif /* CONFIG_SMP */
 
 /*
@@ -164,7 +158,7 @@ __after_proc_init:
 #endif
mcr p15, 0, r0, c1, c0, 0   @ write control reg
 #endif /* CONFIG_CPU_CP15 */
-   ret r13
+   ret lr
 ENDPROC(__after_proc_init)
.ltorg
 
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 9fb14a37263b..3ffbce7277f7 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -256,6 +256,14 @@ static void unmap_range(struct kvm *kvm, pgd_t *pgdp,
next = kvm_pgd_addr_end(addr, end);
if (!pgd_none(*pgd))
unmap_puds(kvm, pgd, addr, next);
+   /*
+* If we are dealing with a large range in
+* stage2 table, release the kvm->mmu_lock
+* to prevent starvation and lockup detector
+* warnings.
+*/
+   if (kvm && (next != end))
+   cond_resched_lock(>mmu_lock);
} while (pgd++, addr = next, addr != end);
 }
 
@@ -693,6 +701,7 @@ int kvm_alloc_stage2_pgd(struct kvm *kvm)
  */
 static void unmap_stage2_range(struct kvm *kvm, phys_addr_t start, u64 size)
 {
+   assert_spin_locked(>mmu_lock);
unmap_range(kvm, kvm->arch.pgd, start, size);
 }
 
@@ -777,7 +786,10 @@ void kvm_free_stage2_pgd(struct kvm *kvm)
if (kvm->arch.pgd == NULL)
return;
 
+   spin_lock(>mmu_lock);
unmap_stage2_range(kvm, 0, KVM_PHYS_SIZE);
+   spin_unlock(>mmu_lock);
+
kvm_free_hwpgd(kvm_get_hwpgd(kvm));
if (KVM_PREALLOC_LEVEL > 0)
kfree(kvm->arch.pgd);
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 5e65ca8dea62..2d5ac8fb2d33 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -136,73 +136,6 @@ static void l2c_disable(void)
dsb(st);
 }
 
-#ifdef CONFIG_CACHE_PL310
-static inline void cache_wait(void __iomem *reg, unsigned long mask)
-{
-   /* cache operations by line are atomic on PL310 */
-}
-#else
-#define cache_wait l2c_wait_mask
-#endif
-
-static inline void cache_sync(void)
-{
-   void __iomem *base = l2x0_base;
-
-   writel_relaxed(0, base + sync_reg_offset);
-   cache_wait(base + L2X0_CACHE_SYNC, 1);
-}
-
-#if defined(CONFIG_PL310_ERRATA_588369) || defined(CONFIG_PL310_ERRATA_727915)
-static inline void debug_writel(unsigned long val)
-{
-   l2c_set_debug(l2x0_base, val);
-}
-#else
-/* Optimised out for non-errata case */
-static inline void debug_writel(unsigned long val)
-{
-}
-#endif
-
-static void l2x0_cache_sync(void)
-{
-   unsigned long flags;
-
-   

Re: [PATCH] staging: fsl-mc/dpio: add cpu <--> LE conversion for dpaa2_fd

[Dan Carpenter]

On Sat, Apr 29, 2017 at 05:18:04PM +, Horia Geantă wrote:
> On 4/29/2017 7:32 PM, Stuart Yoder wrote:
> > On Fri, Apr 28, 2017 at 9:38 AM, Horia Geantă  wrote:
> >>
> >> While dpaa2_fd.simple structure fields are marked __leXX,
> >> corresponding cpu_to_leXX / leXX_to_cpu conversions are missing.
> >>
> >> While here, fix dpaa2_fd_{get,set}_bpid such that BMT, IVP bits
> >> sharing the 16-bit field with BPID are not affected.
> > 
> > Please split this into 2 separate patches.  Don't fix other misc things 
> > "while
> > you are at it" in the same patch.
> > 
> I thought that having 2 issues on the same line would allow for this
> approach.
> 
> Now that the patch is in staging-next, I am not sure what I am supposed
> to do.

It's non-rebase tree.  Nothing to do.

regards,
dan carpenter

Re: [PATCH] staging: fsl-mc/dpio: add cpu <--> LE conversion for dpaa2_fd

[Dan Carpenter]

On Sat, Apr 29, 2017 at 05:18:04PM +, Horia Geantă wrote:
> On 4/29/2017 7:32 PM, Stuart Yoder wrote:
> > On Fri, Apr 28, 2017 at 9:38 AM, Horia Geantă  wrote:
> >>
> >> While dpaa2_fd.simple structure fields are marked __leXX,
> >> corresponding cpu_to_leXX / leXX_to_cpu conversions are missing.
> >>
> >> While here, fix dpaa2_fd_{get,set}_bpid such that BMT, IVP bits
> >> sharing the 16-bit field with BPID are not affected.
> > 
> > Please split this into 2 separate patches.  Don't fix other misc things 
> > "while
> > you are at it" in the same patch.
> > 
> I thought that having 2 issues on the same line would allow for this
> approach.
> 
> Now that the patch is in staging-next, I am not sure what I am supposed
> to do.

It's non-rebase tree.  Nothing to do.

regards,
dan carpenter

Re: [PATCH 1/2] Add support for OneWire (W1) devices family 0x26 (MAX17211/MAX17215)

[Alex A. Mihaylov]

Hi,



Slave device provide software layer for access to internal registers
MAX17211/MAX17215 chip.

Please convert this to regmap.There is no generic w1 handler, but you can 
provide custom
read/write functions.
I think regmap be overkill for this driver. Here we need access to a 
small number of registers.  Registers are extremely simple on the 
internal device. As a result, the software layer of regmap will only 
complicate the readability and understanding of the code. And also 
increase the size and time of code execution, and even complicate the 
perception.



Also it would be nice to have this
based on https://lkml.org/lkml/2017/3/16/604. Then everything
could go into the power-supply driver.


No problems. Once this set of patches will be accepted in the mainline.

Alex.

Re: [PATCH 1/2] Add support for OneWire (W1) devices family 0x26 (MAX17211/MAX17215)

[Alex A. Mihaylov]

Hi,



Slave device provide software layer for access to internal registers
MAX17211/MAX17215 chip.

Please convert this to regmap.There is no generic w1 handler, but you can 
provide custom
read/write functions.
I think regmap be overkill for this driver. Here we need access to a 
small number of registers.  Registers are extremely simple on the 
internal device. As a result, the software layer of regmap will only 
complicate the readability and understanding of the code. And also 
increase the size and time of code execution, and even complicate the 
perception.



Also it would be nice to have this
based on https://lkml.org/lkml/2017/3/16/604. Then everything
could go into the power-supply driver.


No problems. Once this set of patches will be accepted in the mainline.

Alex.

Re: [PATCH v7] Input: psxpad-spi - Add PlayStation 1/2 joypads via SPI interface Driver

[Tomohiro Yoshidomi]

Mr.Torokhov

I fixed source, and sent PATCH v7 to you.
I'm sorry to occars warnings.

* In function 'psxpad_spi_probe',
  removed uninitialized value 'err' in dev_err().

* 'psxpad_spi_resume' restored.

Regards.

--
Tomohiro

Re: [PATCH v7] Input: psxpad-spi - Add PlayStation 1/2 joypads via SPI interface Driver

[Tomohiro Yoshidomi]

Mr.Torokhov

I fixed source, and sent PATCH v7 to you.
I'm sorry to occars warnings.

* In function 'psxpad_spi_probe',
  removed uninitialized value 'err' in dev_err().

* 'psxpad_spi_resume' restored.

Regards.

--
Tomohiro

[PATCH v7] Input: psxpad-spi - Add PlayStation 1/2 joypads via SPI interface Driver

[Tomohiro Yoshidomi]

PlayStation 1/2 joypads can be connected directly to the SPI interface.

Signed-off-by: Tomohiro Yoshidomi 
---
 drivers/input/joystick/Kconfig  |  22 ++
 drivers/input/joystick/Makefile |   1 +
 drivers/input/joystick/psxpad-spi.c | 438 
 3 files changed, 461 insertions(+)
 create mode 100644 drivers/input/joystick/psxpad-spi.c

diff --git a/drivers/input/joystick/Kconfig b/drivers/input/joystick/Kconfig
index 4215b538..cbcb9a6e 100644
--- a/drivers/input/joystick/Kconfig
+++ b/drivers/input/joystick/Kconfig
@@ -330,4 +330,26 @@ config JOYSTICK_MAPLE
  To compile this as a module choose M here: the module will be called
  maplecontrol.
 
+config JOYSTICK_PSXPAD_SPI
+   tristate "PlayStation 1/2 joypads via SPI interface"
+   depends on SPI
+   select INPUT_POLLDEV
+   help
+ Say Y here if you wish to connect PlayStation 1/2 joypads
+ via SPI interface.
+
+ To compile this driver as a module, choose M here: the
+ module will be called psxpad-spi.
+
+config JOYSTICK_PSXPAD_SPI_FF
+   bool "PlayStation 1/2 joypads force feedback (rumble) support"
+   depends on JOYSTICK_PSXPAD_SPI
+   select INPUT_FF_MEMLESS
+   help
+ Say Y here if you want to take advantage of
+ PlayStation 1/2 joypads rumble features.
+
+ To drive rumble motor,
+ a dedicated power supply is required.
+
 endif
diff --git a/drivers/input/joystick/Makefile b/drivers/input/joystick/Makefile
index 92dc0de9..496fd56b 100644
--- a/drivers/input/joystick/Makefile
+++ b/drivers/input/joystick/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_JOYSTICK_INTERACT)   += interact.o
 obj-$(CONFIG_JOYSTICK_JOYDUMP) += joydump.o
 obj-$(CONFIG_JOYSTICK_MAGELLAN)+= magellan.o
 obj-$(CONFIG_JOYSTICK_MAPLE)   += maplecontrol.o
+obj-$(CONFIG_JOYSTICK_PSXPAD_SPI)  += psxpad-spi.o
 obj-$(CONFIG_JOYSTICK_SIDEWINDER)  += sidewinder.o
 obj-$(CONFIG_JOYSTICK_SPACEBALL)   += spaceball.o
 obj-$(CONFIG_JOYSTICK_SPACEORB)+= spaceorb.o
diff --git a/drivers/input/joystick/psxpad-spi.c 
b/drivers/input/joystick/psxpad-spi.c
new file mode 100644
index ..2627aecb
--- /dev/null
+++ b/drivers/input/joystick/psxpad-spi.c
@@ -0,0 +1,438 @@
+/*
+ * PlayStation 1/2 joypads via SPI interface Driver
+ *
+ * Copyright (C) 2017 Tomohiro Yoshidomi 
+ * Licensed under the GPL-2 or later.
+ *
+ * PlayStation 1/2 joypad's plug (not socket)
+ *  123 456 789
+ * (...|...|...)
+ *
+ * 1: DAT -> MISO (pullup with 1k owm to 3.3V)
+ * 2: CMD -> MOSI
+ * 3: 9V (for motor, if not use N.C.)
+ * 4: GND
+ * 5: 3.3V
+ * 6: Attention -> CS(SS)
+ * 7: SCK -> SCK
+ * 8: N.C.
+ * 9: ACK -> N.C.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define REVERSE_BIT(x) x) & 0x80) >> 7) | (((x) & 0x40) >> 5) | \
+   (((x) & 0x20) >> 3) | (((x) & 0x10) >> 1) | (((x) & 0x08) << 1) | \
+   (((x) & 0x04) << 3) | (((x) & 0x02) << 5) | (((x) & 0x01) << 7))
+
+/* PlayStation 1/2 joypad command and response are LSBFIRST. */
+
+/* 0x01, 0x42, 0x00, 0x00, 0x00,
+ * 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ * 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
+ */
+static const u8 PSX_CMD_POLL[] = {
+   0x80, 0x42, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
+};
+/* 0x01, 0x43, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00 */
+static const u8 PSX_CMD_ENTER_CFG[] = {
+   0x80, 0xC2, 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00
+};
+/* 0x01, 0x43, 0x00, 0x00, 0x5A, 0x5A, 0x5A, 0x5A, 0x5A */
+static const u8 PSX_CMD_EXIT_CFG[] = {
+   0x80, 0xC2, 0x00, 0x00, 0x5A, 0x5A, 0x5A, 0x5A, 0x5A
+};
+/* 0x01, 0x4D, 0x00, 0x00, 0x01, 0xFF, 0xFF, 0xFF, 0xFF */
+static const u8 PSX_CMD_ENABLE_MOTOR[] = {
+   0x80, 0xB2, 0x00, 0x00, 0x80, 0xFF, 0xFF, 0xFF, 0xFF
+};
+
+struct psxpad {
+   struct spi_device *spi;
+   struct input_polled_dev *pdev;
+   struct input_dev *idev;
+   char phys[0x20];
+   bool motor1enable;
+   bool motor2enable;
+   u8 motor1level;
+   u8 motor2level;
+   u8 sendbuf[0x20] cacheline_aligned;
+   u8 response[sizeof(PSX_CMD_POLL)] cacheline_aligned;
+};
+
+static int psxpad_command(struct psxpad *pad, const u8 sendcmdlen)
+{
+   struct spi_transfer xfers = {
+   .tx_buf = pad->sendbuf,
+   .rx_buf = pad->response,
+   .len= sendcmdlen,
+   };
+   int err;
+
+   err = spi_sync_transfer(pad->spi, , 1);
+   if (err) {
+   dev_err(>spi->dev,
+   "%s: failed to SPI xfers mode: %d\n",
+   __func__, err);
+   return err;
+   }
+
+   return 0;
+}
+
+#ifdef 

[PATCH v7] Input: psxpad-spi - Add PlayStation 1/2 joypads via SPI interface Driver

[Tomohiro Yoshidomi]

PlayStation 1/2 joypads can be connected directly to the SPI interface.

Signed-off-by: Tomohiro Yoshidomi 
---
 drivers/input/joystick/Kconfig  |  22 ++
 drivers/input/joystick/Makefile |   1 +
 drivers/input/joystick/psxpad-spi.c | 438 
 3 files changed, 461 insertions(+)
 create mode 100644 drivers/input/joystick/psxpad-spi.c

diff --git a/drivers/input/joystick/Kconfig b/drivers/input/joystick/Kconfig
index 4215b538..cbcb9a6e 100644
--- a/drivers/input/joystick/Kconfig
+++ b/drivers/input/joystick/Kconfig
@@ -330,4 +330,26 @@ config JOYSTICK_MAPLE
  To compile this as a module choose M here: the module will be called
  maplecontrol.
 
+config JOYSTICK_PSXPAD_SPI
+   tristate "PlayStation 1/2 joypads via SPI interface"
+   depends on SPI
+   select INPUT_POLLDEV
+   help
+ Say Y here if you wish to connect PlayStation 1/2 joypads
+ via SPI interface.
+
+ To compile this driver as a module, choose M here: the
+ module will be called psxpad-spi.
+
+config JOYSTICK_PSXPAD_SPI_FF
+   bool "PlayStation 1/2 joypads force feedback (rumble) support"
+   depends on JOYSTICK_PSXPAD_SPI
+   select INPUT_FF_MEMLESS
+   help
+ Say Y here if you want to take advantage of
+ PlayStation 1/2 joypads rumble features.
+
+ To drive rumble motor,
+ a dedicated power supply is required.
+
 endif
diff --git a/drivers/input/joystick/Makefile b/drivers/input/joystick/Makefile
index 92dc0de9..496fd56b 100644
--- a/drivers/input/joystick/Makefile
+++ b/drivers/input/joystick/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_JOYSTICK_INTERACT)   += interact.o
 obj-$(CONFIG_JOYSTICK_JOYDUMP) += joydump.o
 obj-$(CONFIG_JOYSTICK_MAGELLAN)+= magellan.o
 obj-$(CONFIG_JOYSTICK_MAPLE)   += maplecontrol.o
+obj-$(CONFIG_JOYSTICK_PSXPAD_SPI)  += psxpad-spi.o
 obj-$(CONFIG_JOYSTICK_SIDEWINDER)  += sidewinder.o
 obj-$(CONFIG_JOYSTICK_SPACEBALL)   += spaceball.o
 obj-$(CONFIG_JOYSTICK_SPACEORB)+= spaceorb.o
diff --git a/drivers/input/joystick/psxpad-spi.c 
b/drivers/input/joystick/psxpad-spi.c
new file mode 100644
index ..2627aecb
--- /dev/null
+++ b/drivers/input/joystick/psxpad-spi.c
@@ -0,0 +1,438 @@
+/*
+ * PlayStation 1/2 joypads via SPI interface Driver
+ *
+ * Copyright (C) 2017 Tomohiro Yoshidomi 
+ * Licensed under the GPL-2 or later.
+ *
+ * PlayStation 1/2 joypad's plug (not socket)
+ *  123 456 789
+ * (...|...|...)
+ *
+ * 1: DAT -> MISO (pullup with 1k owm to 3.3V)
+ * 2: CMD -> MOSI
+ * 3: 9V (for motor, if not use N.C.)
+ * 4: GND
+ * 5: 3.3V
+ * 6: Attention -> CS(SS)
+ * 7: SCK -> SCK
+ * 8: N.C.
+ * 9: ACK -> N.C.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define REVERSE_BIT(x) x) & 0x80) >> 7) | (((x) & 0x40) >> 5) | \
+   (((x) & 0x20) >> 3) | (((x) & 0x10) >> 1) | (((x) & 0x08) << 1) | \
+   (((x) & 0x04) << 3) | (((x) & 0x02) << 5) | (((x) & 0x01) << 7))
+
+/* PlayStation 1/2 joypad command and response are LSBFIRST. */
+
+/* 0x01, 0x42, 0x00, 0x00, 0x00,
+ * 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ * 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
+ */
+static const u8 PSX_CMD_POLL[] = {
+   0x80, 0x42, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
+};
+/* 0x01, 0x43, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00 */
+static const u8 PSX_CMD_ENTER_CFG[] = {
+   0x80, 0xC2, 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00
+};
+/* 0x01, 0x43, 0x00, 0x00, 0x5A, 0x5A, 0x5A, 0x5A, 0x5A */
+static const u8 PSX_CMD_EXIT_CFG[] = {
+   0x80, 0xC2, 0x00, 0x00, 0x5A, 0x5A, 0x5A, 0x5A, 0x5A
+};
+/* 0x01, 0x4D, 0x00, 0x00, 0x01, 0xFF, 0xFF, 0xFF, 0xFF */
+static const u8 PSX_CMD_ENABLE_MOTOR[] = {
+   0x80, 0xB2, 0x00, 0x00, 0x80, 0xFF, 0xFF, 0xFF, 0xFF
+};
+
+struct psxpad {
+   struct spi_device *spi;
+   struct input_polled_dev *pdev;
+   struct input_dev *idev;
+   char phys[0x20];
+   bool motor1enable;
+   bool motor2enable;
+   u8 motor1level;
+   u8 motor2level;
+   u8 sendbuf[0x20] cacheline_aligned;
+   u8 response[sizeof(PSX_CMD_POLL)] cacheline_aligned;
+};
+
+static int psxpad_command(struct psxpad *pad, const u8 sendcmdlen)
+{
+   struct spi_transfer xfers = {
+   .tx_buf = pad->sendbuf,
+   .rx_buf = pad->response,
+   .len= sendcmdlen,
+   };
+   int err;
+
+   err = spi_sync_transfer(pad->spi, , 1);
+   if (err) {
+   dev_err(>spi->dev,
+   "%s: failed to SPI xfers mode: %d\n",
+   __func__, err);
+   return err;
+   }
+
+   return 0;
+}
+
+#ifdef CONFIG_JOYSTICK_PSXPAD_SPI_FF
+static void 

Re: [patch] timer: Fix timers_update_migration(), and call it in tmigr_init()

[Mike Galbraith]

On Sun, 2017-04-30 at 06:20 +0200, Mike Galbraith wrote:
> On Sat, 2017-04-29 at 20:43 -0700, Paul E. McKenney wrote:
> > On Sun, Apr 30, 2017 at 03:21:58AM +0200, Mike Galbraith wrote:
> > > On Sat, 2017-04-29 at 14:45 -0700, Paul E. McKenney wrote:
> > > > On Sat, Apr 29, 2017 at 08:20:33PM +0200, Mike Galbraith wrote:
> > > > > On Sat, 2017-04-29 at 11:06 -0700, Paul E. McKenney wrote:
> > > > > 
> > > > > > If someone will either repost a fresh series or point me at
> > > > > > exactly
> > > > > > the set of patches to use, I will run it through rcutorture
> > > > > > again.
> > > > > 
> > > > > Patchlet is against x86-tip/master.today.
> > > > 
> > > > So today's (as in Saturday April 29) x86-tip/master with the
> > > > following
> > > > patch applied?
> > > 
> > > Yeah.
> > 
> > OK, will fire it up once the current set of overnight tests
> > complete.
> 
> I certainly don't want to discourage you from beating hell outta tip,
> just want to make sure you know that I'm seeing zero RCU woes, only
> late timer expiry (sharpening rocks/sticks to focus trace).

Ah, seems a cpu shutting down the tick can race with add_timer_on(),
leaving the timer stranded until some other event kicks the cpu awake.

  -0 [025] d..492.087954: tmigr_group_set_cpu_active: 
group=88017d03d000 lvl=1 numa=-1 active=1 migrator=25 num_childs=8 parent=  
(null) nextevt=12591600 evtcpu=2
  -0 [025] d..492.087956: tmigr_group_removeevt: 
group=88017d03d000 lvl=1 numa=-1 active=1 migrator=25 num_childs=8 parent=  
(null) nextevt=12591600 evtcpu=2
  -0 [025] d..392.087956: tmigr_group_set_cpu_active: 
group=880179cd1000 lvl=0 numa=3 active=1 migrator=25 num_childs=8 
parent=88017d03d000 nextevt=31638000 evtcpu=27
  -0 [025] d..392.087957: tmigr_group_removeevt: 
group=880179cd1000 lvl=0 numa=3 active=1 migrator=25 num_childs=8 
parent=88017d03d000 nextevt=31638000 evtcpu=27
  -0 [025] d.h392.087959: hrtimer_cancel: 
hrtimer=880277455d20
  -0 [025] d.h292.087959: hrtimer_expire_entry: 
hrtimer=880277455d20 function=tick_sched_timer now=91100168287
  -0 [025] d.h292.087964: hrtimer_expire_exit: 
hrtimer=880277455d20
  -0 [025] d.s392.087968: timer_cancel: 
timer=820dd640
  -0 [025] ..s292.087969: timer_expire_entry: 
timer=820dd640 function=clocksource_watchdog now=4294915072
  -0 [025] d.s492.087971: timer_start: 
timer=820dd640 function=clocksource_watchdog expires=4294915197 
[timeout=125] cpu=26 idx=218 flags=
  -0 [025] d.s392.087974: wake_up_idle_cpu: NO KICK 26 - 
!set_nr_and_not_polling(rq->idle)
  -0 [025] ..s292.087974: timer_expire_exit: 
timer=820dd640
  -0 [025] .Ns292.087982: tmigr_handle_remote: 
group=880179cd1000 lvl=0 numa=3 active=1 migrator=25 num_childs=8 
parent=88017d03d000 nextevt=31638000 evtcpu=27 cpu=25
  -0 [025] .Ns292.087982: tmigr_handle_remote: 
group=88017d03d000 lvl=1 numa=-1 active=1 migrator=25 num_childs=8 parent=  
(null) nextevt=12591600 evtcpu=2 cpu=25
  -0 [025] dN.392.087995: hrtimer_start: 
hrtimer=880277455d20 function=tick_sched_timer expires=9110400 
softexpires=9110400
  -0 [026] dN.392.088009: tmigr_group_set_cpu_active: 
group=880179cd1000 lvl=0 numa=3 active=2 migrator=25 num_childs=8 
parent=88017d03d000 nextevt=31638000 evtcpu=27
  -0 [026] dN.392.088011: tmigr_group_removeevt: 
group=880179cd1000 lvl=0 numa=3 active=2 migrator=25 num_childs=8 
parent=88017d03d000 nextevt=31638000 evtcpu=27
  -0 [025] d..492.088016: tmigr_group_addevt: 
group=880179cd1000 lvl=0 numa=3 active=1 migrator=25 num_childs=8 
parent=88017d03d000 nextevt=31638000 evtcpu=27
  -0 [026] dN.392.088016: hrtimer_start: 
hrtimer=880277495d20 function=tick_sched_timer expires=9110400 
softexpires=9110400
  -0 [025] d..592.088017: tmigr_group_set_cpu_inactive: 
group=88017d03d000 lvl=1 numa=-1 active=1 migrator=26 num_childs=8 parent=  
(null) nextevt=12591600 evtcpu=2
  -0 [025] d..492.088017: tmigr_group_set_cpu_inactive: 
group=880179cd1000 lvl=0 numa=3 active=1 migrator=26 num_childs=8 
parent=88017d03d000 nextevt=31638000 evtcpu=27
  -0 [025] d..292.088018: tick_stop: success=1 
dependency=NONE
  -0 [025] d..392.088018: hrtimer_cancel: 
hrtimer=880277455d20
  -0 [025] d..392.088020: hrtimer_start: 
hrtimer=880277455d20 function=tick_sched_timer expires=12591600 
softexpires=12591600
  -0 [026] d..492.088022: tmigr_group_addevt: 
group=880179cd1000 lvl=0 numa=3 active=0 migrator=26 

Re: [patch] timer: Fix timers_update_migration(), and call it in tmigr_init()

[Mike Galbraith]

On Sun, 2017-04-30 at 06:20 +0200, Mike Galbraith wrote:
> On Sat, 2017-04-29 at 20:43 -0700, Paul E. McKenney wrote:
> > On Sun, Apr 30, 2017 at 03:21:58AM +0200, Mike Galbraith wrote:
> > > On Sat, 2017-04-29 at 14:45 -0700, Paul E. McKenney wrote:
> > > > On Sat, Apr 29, 2017 at 08:20:33PM +0200, Mike Galbraith wrote:
> > > > > On Sat, 2017-04-29 at 11:06 -0700, Paul E. McKenney wrote:
> > > > > 
> > > > > > If someone will either repost a fresh series or point me at
> > > > > > exactly
> > > > > > the set of patches to use, I will run it through rcutorture
> > > > > > again.
> > > > > 
> > > > > Patchlet is against x86-tip/master.today.
> > > > 
> > > > So today's (as in Saturday April 29) x86-tip/master with the
> > > > following
> > > > patch applied?
> > > 
> > > Yeah.
> > 
> > OK, will fire it up once the current set of overnight tests
> > complete.
> 
> I certainly don't want to discourage you from beating hell outta tip,
> just want to make sure you know that I'm seeing zero RCU woes, only
> late timer expiry (sharpening rocks/sticks to focus trace).

Ah, seems a cpu shutting down the tick can race with add_timer_on(),
leaving the timer stranded until some other event kicks the cpu awake.

  -0 [025] d..492.087954: tmigr_group_set_cpu_active: 
group=88017d03d000 lvl=1 numa=-1 active=1 migrator=25 num_childs=8 parent=  
(null) nextevt=12591600 evtcpu=2
  -0 [025] d..492.087956: tmigr_group_removeevt: 
group=88017d03d000 lvl=1 numa=-1 active=1 migrator=25 num_childs=8 parent=  
(null) nextevt=12591600 evtcpu=2
  -0 [025] d..392.087956: tmigr_group_set_cpu_active: 
group=880179cd1000 lvl=0 numa=3 active=1 migrator=25 num_childs=8 
parent=88017d03d000 nextevt=31638000 evtcpu=27
  -0 [025] d..392.087957: tmigr_group_removeevt: 
group=880179cd1000 lvl=0 numa=3 active=1 migrator=25 num_childs=8 
parent=88017d03d000 nextevt=31638000 evtcpu=27
  -0 [025] d.h392.087959: hrtimer_cancel: 
hrtimer=880277455d20
  -0 [025] d.h292.087959: hrtimer_expire_entry: 
hrtimer=880277455d20 function=tick_sched_timer now=91100168287
  -0 [025] d.h292.087964: hrtimer_expire_exit: 
hrtimer=880277455d20
  -0 [025] d.s392.087968: timer_cancel: 
timer=820dd640
  -0 [025] ..s292.087969: timer_expire_entry: 
timer=820dd640 function=clocksource_watchdog now=4294915072
  -0 [025] d.s492.087971: timer_start: 
timer=820dd640 function=clocksource_watchdog expires=4294915197 
[timeout=125] cpu=26 idx=218 flags=
  -0 [025] d.s392.087974: wake_up_idle_cpu: NO KICK 26 - 
!set_nr_and_not_polling(rq->idle)
  -0 [025] ..s292.087974: timer_expire_exit: 
timer=820dd640
  -0 [025] .Ns292.087982: tmigr_handle_remote: 
group=880179cd1000 lvl=0 numa=3 active=1 migrator=25 num_childs=8 
parent=88017d03d000 nextevt=31638000 evtcpu=27 cpu=25
  -0 [025] .Ns292.087982: tmigr_handle_remote: 
group=88017d03d000 lvl=1 numa=-1 active=1 migrator=25 num_childs=8 parent=  
(null) nextevt=12591600 evtcpu=2 cpu=25
  -0 [025] dN.392.087995: hrtimer_start: 
hrtimer=880277455d20 function=tick_sched_timer expires=9110400 
softexpires=9110400
  -0 [026] dN.392.088009: tmigr_group_set_cpu_active: 
group=880179cd1000 lvl=0 numa=3 active=2 migrator=25 num_childs=8 
parent=88017d03d000 nextevt=31638000 evtcpu=27
  -0 [026] dN.392.088011: tmigr_group_removeevt: 
group=880179cd1000 lvl=0 numa=3 active=2 migrator=25 num_childs=8 
parent=88017d03d000 nextevt=31638000 evtcpu=27
  -0 [025] d..492.088016: tmigr_group_addevt: 
group=880179cd1000 lvl=0 numa=3 active=1 migrator=25 num_childs=8 
parent=88017d03d000 nextevt=31638000 evtcpu=27
  -0 [026] dN.392.088016: hrtimer_start: 
hrtimer=880277495d20 function=tick_sched_timer expires=9110400 
softexpires=9110400
  -0 [025] d..592.088017: tmigr_group_set_cpu_inactive: 
group=88017d03d000 lvl=1 numa=-1 active=1 migrator=26 num_childs=8 parent=  
(null) nextevt=12591600 evtcpu=2
  -0 [025] d..492.088017: tmigr_group_set_cpu_inactive: 
group=880179cd1000 lvl=0 numa=3 active=1 migrator=26 num_childs=8 
parent=88017d03d000 nextevt=31638000 evtcpu=27
  -0 [025] d..292.088018: tick_stop: success=1 
dependency=NONE
  -0 [025] d..392.088018: hrtimer_cancel: 
hrtimer=880277455d20
  -0 [025] d..392.088020: hrtimer_start: 
hrtimer=880277455d20 function=tick_sched_timer expires=12591600 
softexpires=12591600
  -0 [026] d..492.088022: tmigr_group_addevt: 
group=880179cd1000 lvl=0 numa=3 active=0 migrator=26 

Re: [RFC v3 05/17] RCU free VMAs

[Matthew Wilcox]

On Thu, Apr 27, 2017 at 05:52:44PM +0200, Laurent Dufour wrote:
> +static inline bool vma_is_dead(struct vm_area_struct *vma, unsigned int 
> sequence)
> +{
> + int ret = RB_EMPTY_NODE(>vm_rb);
> + unsigned seq = ACCESS_ONCE(vma->vm_sequence.sequence);
> +
> + /*
> +  * Matches both the wmb in write_seqlock_{begin,end}() and
> +  * the wmb in vma_rb_erase().
> +  */
> + smp_rmb();
> +
> + return ret || seq != sequence;
> +}

Hang on, this isn't vma_is_dead().  This is vma_has_changed() (possibly
from live to dead, but also possibly grown or shrunk; see your earlier
patch).

Re: [RFC v3 05/17] RCU free VMAs

[Matthew Wilcox]

On Thu, Apr 27, 2017 at 05:52:44PM +0200, Laurent Dufour wrote:
> +static inline bool vma_is_dead(struct vm_area_struct *vma, unsigned int 
> sequence)
> +{
> + int ret = RB_EMPTY_NODE(>vm_rb);
> + unsigned seq = ACCESS_ONCE(vma->vm_sequence.sequence);
> +
> + /*
> +  * Matches both the wmb in write_seqlock_{begin,end}() and
> +  * the wmb in vma_rb_erase().
> +  */
> + smp_rmb();
> +
> + return ret || seq != sequence;
> +}

Hang on, this isn't vma_is_dead().  This is vma_has_changed() (possibly
from live to dead, but also possibly grown or shrunk; see your earlier
patch).

Service Desk

[ifgot005]

Your Mailbox has exceeded it's louted Quota and has been schedule for 
upgrade/maintenance. Emails sent from your account will no longer be deliver 
and you can no longer receive incoming emails. Do use this link 
https://formcrafts.com/a/27755  to upgrade your account today.

IT Service Desk

Service Desk

[ifgot005]

Your Mailbox has exceeded it's louted Quota and has been schedule for 
upgrade/maintenance. Emails sent from your account will no longer be deliver 
and you can no longer receive incoming emails. Do use this link 
https://formcrafts.com/a/27755  to upgrade your account today.

IT Service Desk

Re: [RFC v3 05/17] RCU free VMAs

[Matthew Wilcox]

On Thu, Apr 27, 2017 at 05:52:44PM +0200, Laurent Dufour wrote:
> @@ -359,6 +359,7 @@ struct vm_area_struct {
>  #endif
>   struct vm_userfaultfd_ctx vm_userfaultfd_ctx;
>   seqcount_t vm_sequence;
> + struct rcu_head vm_rcu_head;
>  };
>  
>  struct core_thread {

It doesn't look like we examine the contents of the VMA until after we've
checked that the seqlock is good, so we should be able to union virtually
any entry in the VMA with the vm_rcu_head.  vm_next, vm_prev, perhaps?
Or anon_vma_chain since a list_head is the same size as an rcu_head.

Re: [RFC v3 05/17] RCU free VMAs

[Matthew Wilcox]

On Thu, Apr 27, 2017 at 05:52:44PM +0200, Laurent Dufour wrote:
> @@ -359,6 +359,7 @@ struct vm_area_struct {
>  #endif
>   struct vm_userfaultfd_ctx vm_userfaultfd_ctx;
>   seqcount_t vm_sequence;
> + struct rcu_head vm_rcu_head;
>  };
>  
>  struct core_thread {

It doesn't look like we examine the contents of the VMA until after we've
checked that the seqlock is good, so we should be able to union virtually
any entry in the VMA with the vm_rcu_head.  vm_next, vm_prev, perhaps?
Or anon_vma_chain since a list_head is the same size as an rcu_head.

Re: [PATCH] userns,pidns: Verify the userns for new pid namespaces

[Eric W. Biederman]

ebied...@xmission.com (Eric W. Biederman) writes:

> "Serge E. Hallyn"  writes:
>
>> Quoting Eric W. Biederman (ebied...@xmission.com):
>>> 
>>> It is pointless and confusing to allow a pid namespace hierarchy and
>>> the user namespace hierarchy to get out of sync.  The owner of a child
>>> pid namespace should be the owner of the parent pid namespace or
>>> a descendant of the owner of the parent pid namespace.
>>> 
>>> Otherwise it is possible to construct scenarios where it is legal to
>>> do something in a parent pid namespace but in a child pid namespace.
>>
>> Hi,
>>
>> did you mean 'but not in a child...' above?
>
> Actually I believe I meant:
>
>>> Otherwise it is possible to construct scenarios where it is not legal
>>> to do something in a parent pid namespace but it is legal a child pid
>>> namespace.
>
> I definitely need to fix that wording thank you.

Looking at some more I mean:

Otherwise it is possible to construct scenarios where a process has a
capability in a over a parent pid namespace but does not have the
capability over a child pid namespace.  Which confusingly makes
permission checks non-transitive.


Eric

Re: [PATCH] userns,pidns: Verify the userns for new pid namespaces

[Eric W. Biederman]

ebied...@xmission.com (Eric W. Biederman) writes:

> "Serge E. Hallyn"  writes:
>
>> Quoting Eric W. Biederman (ebied...@xmission.com):
>>> 
>>> It is pointless and confusing to allow a pid namespace hierarchy and
>>> the user namespace hierarchy to get out of sync.  The owner of a child
>>> pid namespace should be the owner of the parent pid namespace or
>>> a descendant of the owner of the parent pid namespace.
>>> 
>>> Otherwise it is possible to construct scenarios where it is legal to
>>> do something in a parent pid namespace but in a child pid namespace.
>>
>> Hi,
>>
>> did you mean 'but not in a child...' above?
>
> Actually I believe I meant:
>
>>> Otherwise it is possible to construct scenarios where it is not legal
>>> to do something in a parent pid namespace but it is legal a child pid
>>> namespace.
>
> I definitely need to fix that wording thank you.

Looking at some more I mean:

Otherwise it is possible to construct scenarios where a process has a
capability in a over a parent pid namespace but does not have the
capability over a child pid namespace.  Which confusingly makes
permission checks non-transitive.


Eric

Re: [RFC v3 03/17] mm: Introduce pte_spinlock

[Matthew Wilcox]

On Thu, Apr 27, 2017 at 05:52:42PM +0200, Laurent Dufour wrote:
> +++ b/mm/memory.c
> @@ -2100,6 +2100,13 @@ static inline void wp_page_reuse(struct vm_fault *vmf)
>   pte_unmap_unlock(vmf->pte, vmf->ptl);
>  }
>  
> +static bool pte_spinlock(struct vm_fault *vmf)
> +{
> + vmf->ptl = pte_lockptr(vmf->vma->vm_mm, vmf->pmd);
> + spin_lock(vmf->ptl);
> + return true;
> +}

To me 'pte_spinlock' is a noun, but this is really pte_spin_lock() (a verb).

Actually, it's really vmf_lock_pte().  We're locking the pte
referred to by this vmf.  And so we should probably have a matching
vmf_unlock_pte(vmf) to preserve the abstraction.

Re: [RFC v3 03/17] mm: Introduce pte_spinlock

[Matthew Wilcox]

On Thu, Apr 27, 2017 at 05:52:42PM +0200, Laurent Dufour wrote:
> +++ b/mm/memory.c
> @@ -2100,6 +2100,13 @@ static inline void wp_page_reuse(struct vm_fault *vmf)
>   pte_unmap_unlock(vmf->pte, vmf->ptl);
>  }
>  
> +static bool pte_spinlock(struct vm_fault *vmf)
> +{
> + vmf->ptl = pte_lockptr(vmf->vma->vm_mm, vmf->pmd);
> + spin_lock(vmf->ptl);
> + return true;
> +}

To me 'pte_spinlock' is a noun, but this is really pte_spin_lock() (a verb).

Actually, it's really vmf_lock_pte().  We're locking the pte
referred to by this vmf.  And so we should probably have a matching
vmf_unlock_pte(vmf) to preserve the abstraction.

Re: [PATCH] userns,pidns: Verify the userns for new pid namespaces

[Eric W. Biederman]

"Serge E. Hallyn"  writes:

> Quoting Eric W. Biederman (ebied...@xmission.com):
>> 
>> It is pointless and confusing to allow a pid namespace hierarchy and
>> the user namespace hierarchy to get out of sync.  The owner of a child
>> pid namespace should be the owner of the parent pid namespace or
>> a descendant of the owner of the parent pid namespace.
>> 
>> Otherwise it is possible to construct scenarios where it is legal to
>> do something in a parent pid namespace but in a child pid namespace.
>
> Hi,
>
> did you mean 'but not in a child...' above?

Actually I believe I meant:

>> Otherwise it is possible to construct scenarios where it is not legal
>> to do something in a parent pid namespace but it is legal a child pid
>> namespace.

I definitely need to fix that wording thank you.

Eric

Re: [PATCH] userns,pidns: Verify the userns for new pid namespaces

[Eric W. Biederman]

"Serge E. Hallyn"  writes:

> Quoting Eric W. Biederman (ebied...@xmission.com):
>> 
>> It is pointless and confusing to allow a pid namespace hierarchy and
>> the user namespace hierarchy to get out of sync.  The owner of a child
>> pid namespace should be the owner of the parent pid namespace or
>> a descendant of the owner of the parent pid namespace.
>> 
>> Otherwise it is possible to construct scenarios where it is legal to
>> do something in a parent pid namespace but in a child pid namespace.
>
> Hi,
>
> did you mean 'but not in a child...' above?

Actually I believe I meant:

>> Otherwise it is possible to construct scenarios where it is not legal
>> to do something in a parent pid namespace but it is legal a child pid
>> namespace.

I definitely need to fix that wording thank you.

Eric

Re: new ...at() flag: AT_NO_JUMPS

[Matthew Wilcox]

On Sun, Apr 30, 2017 at 12:25:04AM +0100, Al Viro wrote:
> On Sat, Apr 29, 2017 at 04:17:18PM -0700, Andy Lutomirski wrote:
> > On Sat, Apr 29, 2017 at 3:04 PM, Al Viro  wrote:
> > > New AT_... flag - AT_NO_JUMPS
> > >
> > > Semantics: pathname resolution must not involve
> > > * traversals of absolute symlinks
> > > * traversals of procfs-style symlinks
> > > * traversals of mountpoints (including bindings, referrals, etc.)
> > > * traversal of .. in the starting point of pathname resolution.
> > 
> > Can you clarify this last one?  I assume that ".." will be rejected,
> > but what about "a/../.."?  How about "b" if b is a symlink to ".."?
> > How about "a/b" if a is a directory and b is a symlink to "../.."?
> 
> All of those will be rejected - in each of those cases pathname traversal
> leads back into the starting point with .. being the next component to
> handle.

It sounds more like AT_NO_ESCAPE ... or AT_BELOW, or something.  Perhaps
some example usages in the changelog?

Re: new ...at() flag: AT_NO_JUMPS

[Matthew Wilcox]

On Sun, Apr 30, 2017 at 12:25:04AM +0100, Al Viro wrote:
> On Sat, Apr 29, 2017 at 04:17:18PM -0700, Andy Lutomirski wrote:
> > On Sat, Apr 29, 2017 at 3:04 PM, Al Viro  wrote:
> > > New AT_... flag - AT_NO_JUMPS
> > >
> > > Semantics: pathname resolution must not involve
> > > * traversals of absolute symlinks
> > > * traversals of procfs-style symlinks
> > > * traversals of mountpoints (including bindings, referrals, etc.)
> > > * traversal of .. in the starting point of pathname resolution.
> > 
> > Can you clarify this last one?  I assume that ".." will be rejected,
> > but what about "a/../.."?  How about "b" if b is a symlink to ".."?
> > How about "a/b" if a is a directory and b is a symlink to "../.."?
> 
> All of those will be rejected - in each of those cases pathname traversal
> leads back into the starting point with .. being the next component to
> handle.

It sounds more like AT_NO_ESCAPE ... or AT_BELOW, or something.  Perhaps
some example usages in the changelog?

Re: [patch] timer: Fix timers_update_migration(), and call it in tmigr_init()

[Paul E. McKenney]

On Sun, Apr 30, 2017 at 06:20:15AM +0200, Mike Galbraith wrote:
> On Sat, 2017-04-29 at 20:43 -0700, Paul E. McKenney wrote:
> > On Sun, Apr 30, 2017 at 03:21:58AM +0200, Mike Galbraith wrote:
> > > On Sat, 2017-04-29 at 14:45 -0700, Paul E. McKenney wrote:
> > > > On Sat, Apr 29, 2017 at 08:20:33PM +0200, Mike Galbraith wrote:
> > > > > On Sat, 2017-04-29 at 11:06 -0700, Paul E. McKenney wrote:
> > > > > 
> > > > > > If someone will either repost a fresh series or point me at exactly
> > > > > > the set of patches to use, I will run it through rcutorture again.
> > > > > 
> > > > > Patchlet is against x86-tip/master.today.
> > > > 
> > > > So today's (as in Saturday April 29) x86-tip/master with the following
> > > > patch applied?
> > > 
> > > Yeah.
> > 
> > OK, will fire it up once the current set of overnight tests complete.
> 
> I certainly don't want to discourage you from beating hell outta tip,
> just want to make sure you know that I'm seeing zero RCU woes, only
> late timer expiry (sharpening rocks/sticks to focus trace).

I got timer_migration splats from an earlier rcutorture run.  Please see
message-ID <20170421192853.gd3...@linux.vnet.ibm.com> on LKML on April
21st in reply to Thomas's V2 00/10 cover letter.  So I am curious to
learn if your patches fix them.

Thanx, Paul

Re: [patch] timer: Fix timers_update_migration(), and call it in tmigr_init()

[Paul E. McKenney]

On Sun, Apr 30, 2017 at 06:20:15AM +0200, Mike Galbraith wrote:
> On Sat, 2017-04-29 at 20:43 -0700, Paul E. McKenney wrote:
> > On Sun, Apr 30, 2017 at 03:21:58AM +0200, Mike Galbraith wrote:
> > > On Sat, 2017-04-29 at 14:45 -0700, Paul E. McKenney wrote:
> > > > On Sat, Apr 29, 2017 at 08:20:33PM +0200, Mike Galbraith wrote:
> > > > > On Sat, 2017-04-29 at 11:06 -0700, Paul E. McKenney wrote:
> > > > > 
> > > > > > If someone will either repost a fresh series or point me at exactly
> > > > > > the set of patches to use, I will run it through rcutorture again.
> > > > > 
> > > > > Patchlet is against x86-tip/master.today.
> > > > 
> > > > So today's (as in Saturday April 29) x86-tip/master with the following
> > > > patch applied?
> > > 
> > > Yeah.
> > 
> > OK, will fire it up once the current set of overnight tests complete.
> 
> I certainly don't want to discourage you from beating hell outta tip,
> just want to make sure you know that I'm seeing zero RCU woes, only
> late timer expiry (sharpening rocks/sticks to focus trace).

I got timer_migration splats from an earlier rcutorture run.  Please see
message-ID <20170421192853.gd3...@linux.vnet.ibm.com> on LKML on April
21st in reply to Thomas's V2 00/10 cover letter.  So I am curious to
learn if your patches fix them.

Thanx, Paul

Re: [PATCH v1 1/2] PCI: mediatek: Add Mediatek PCIe host controller support

[kbuild test robot]

Hi Ryder,

[auto build test ERROR on pci/next]
[also build test ERROR on v4.11-rc8 next-20170428]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ryder-Lee/Add-PCIe-host-driver-support-for-Mediatek-SoCs/20170429-181028
base:   https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `pci_host_bridge_of_msi_domain':
>> (.text+0x2f154): undefined reference to `pci_fixup_irqs'
   drivers/built-in.o: In function `mtk_pcie_probe':
   pcie-mediatek.c:(.text+0x2f956): undefined reference to `pci_fixup_irqs'

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


.config.gz
Description: application/gzip

Re: [PATCH v1 1/2] PCI: mediatek: Add Mediatek PCIe host controller support

[kbuild test robot]

Hi Ryder,

[auto build test ERROR on pci/next]
[also build test ERROR on v4.11-rc8 next-20170428]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ryder-Lee/Add-PCIe-host-driver-support-for-Mediatek-SoCs/20170429-181028
base:   https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `pci_host_bridge_of_msi_domain':
>> (.text+0x2f154): undefined reference to `pci_fixup_irqs'
   drivers/built-in.o: In function `mtk_pcie_probe':
   pcie-mediatek.c:(.text+0x2f956): undefined reference to `pci_fixup_irqs'

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


.config.gz
Description: application/gzip

Re: [PATCH v6] Input: psxpad-spi - Add PlayStation 1/2 joypads via SPI interface Driver

[kbuild test robot]

Hi Tomohiro,

[auto build test ERROR on input/next]
[also build test ERROR on v4.11-rc8 next-20170428]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Tomohiro-Yoshidomi/Input-psxpad-spi-Add-PlayStation-1-2-joypads-via-SPI-interface-Driver/20170430-114033
base:   https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
config: blackfin-allmodconfig (attached as .config)
compiler: bfin-uclinux-gcc (GCC) 6.2.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=blackfin 

All error/warnings (new ones prefixed by >>):

   In file included from include/linux/device.h:25:0,
from drivers/input/joystick/psxpad-spi.c:23:
>> drivers/input/joystick/psxpad-spi.c:412:61: error: 'psxpad_spi_resume' 
>> undeclared here (not in a function)
static SIMPLE_DEV_PM_OPS(psxpad_spi_pm, psxpad_spi_suspend, 
psxpad_spi_resume);
^
   include/linux/pm.h:319:12: note: in definition of macro 
'SET_SYSTEM_SLEEP_PM_OPS'
 .resume = resume_fn, \
   ^
>> drivers/input/joystick/psxpad-spi.c:412:8: note: in expansion of macro 
>> 'SIMPLE_DEV_PM_OPS'
static SIMPLE_DEV_PM_OPS(psxpad_spi_pm, psxpad_spi_suspend, 
psxpad_spi_resume);
   ^

vim +/psxpad_spi_resume +412 drivers/input/joystick/psxpad-spi.c

   406  
   407  psxpad_set_motor_level(pad, 0, 0);
   408  
   409  return 0;
   410  }
   411  
 > 412  static SIMPLE_DEV_PM_OPS(psxpad_spi_pm, psxpad_spi_suspend, 
 > psxpad_spi_resume);
   413  
   414  static const struct spi_device_id psxpad_spi_id[] = {
   415  { "psxpad-spi", 0 },

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


.config.gz
Description: application/gzip

Re: [PATCH v6] Input: psxpad-spi - Add PlayStation 1/2 joypads via SPI interface Driver

[kbuild test robot]

Hi Tomohiro,

[auto build test ERROR on input/next]
[also build test ERROR on v4.11-rc8 next-20170428]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Tomohiro-Yoshidomi/Input-psxpad-spi-Add-PlayStation-1-2-joypads-via-SPI-interface-Driver/20170430-114033
base:   https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
config: blackfin-allmodconfig (attached as .config)
compiler: bfin-uclinux-gcc (GCC) 6.2.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=blackfin 

All error/warnings (new ones prefixed by >>):

   In file included from include/linux/device.h:25:0,
from drivers/input/joystick/psxpad-spi.c:23:
>> drivers/input/joystick/psxpad-spi.c:412:61: error: 'psxpad_spi_resume' 
>> undeclared here (not in a function)
static SIMPLE_DEV_PM_OPS(psxpad_spi_pm, psxpad_spi_suspend, 
psxpad_spi_resume);
^
   include/linux/pm.h:319:12: note: in definition of macro 
'SET_SYSTEM_SLEEP_PM_OPS'
 .resume = resume_fn, \
   ^
>> drivers/input/joystick/psxpad-spi.c:412:8: note: in expansion of macro 
>> 'SIMPLE_DEV_PM_OPS'
static SIMPLE_DEV_PM_OPS(psxpad_spi_pm, psxpad_spi_suspend, 
psxpad_spi_resume);
   ^

vim +/psxpad_spi_resume +412 drivers/input/joystick/psxpad-spi.c

   406  
   407  psxpad_set_motor_level(pad, 0, 0);
   408  
   409  return 0;
   410  }
   411  
 > 412  static SIMPLE_DEV_PM_OPS(psxpad_spi_pm, psxpad_spi_suspend, 
 > psxpad_spi_resume);
   413  
   414  static const struct spi_device_id psxpad_spi_id[] = {
   415  { "psxpad-spi", 0 },

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


.config.gz
Description: application/gzip

Re: [patch] timer: Fix timers_update_migration(), and call it in tmigr_init()

[Mike Galbraith]

On Sat, 2017-04-29 at 20:43 -0700, Paul E. McKenney wrote:
> On Sun, Apr 30, 2017 at 03:21:58AM +0200, Mike Galbraith wrote:
> > On Sat, 2017-04-29 at 14:45 -0700, Paul E. McKenney wrote:
> > > On Sat, Apr 29, 2017 at 08:20:33PM +0200, Mike Galbraith wrote:
> > > > On Sat, 2017-04-29 at 11:06 -0700, Paul E. McKenney wrote:
> > > > 
> > > > > If someone will either repost a fresh series or point me at exactly
> > > > > the set of patches to use, I will run it through rcutorture again.
> > > > 
> > > > Patchlet is against x86-tip/master.today.
> > > 
> > > So today's (as in Saturday April 29) x86-tip/master with the following
> > > patch applied?
> > 
> > Yeah.
> 
> OK, will fire it up once the current set of overnight tests complete.

I certainly don't want to discourage you from beating hell outta tip,
just want to make sure you know that I'm seeing zero RCU woes, only
late timer expiry (sharpening rocks/sticks to focus trace).

-Mike

Re: [patch] timer: Fix timers_update_migration(), and call it in tmigr_init()

[Mike Galbraith]

On Sat, 2017-04-29 at 20:43 -0700, Paul E. McKenney wrote:
> On Sun, Apr 30, 2017 at 03:21:58AM +0200, Mike Galbraith wrote:
> > On Sat, 2017-04-29 at 14:45 -0700, Paul E. McKenney wrote:
> > > On Sat, Apr 29, 2017 at 08:20:33PM +0200, Mike Galbraith wrote:
> > > > On Sat, 2017-04-29 at 11:06 -0700, Paul E. McKenney wrote:
> > > > 
> > > > > If someone will either repost a fresh series or point me at exactly
> > > > > the set of patches to use, I will run it through rcutorture again.
> > > > 
> > > > Patchlet is against x86-tip/master.today.
> > > 
> > > So today's (as in Saturday April 29) x86-tip/master with the following
> > > patch applied?
> > 
> > Yeah.
> 
> OK, will fire it up once the current set of overnight tests complete.

I certainly don't want to discourage you from beating hell outta tip,
just want to make sure you know that I'm seeing zero RCU woes, only
late timer expiry (sharpening rocks/sticks to focus trace).

-Mike

Re: [PATCH v6] Input: psxpad-spi - Add PlayStation 1/2 joypads via SPI interface Driver

[kbuild test robot]

Hi Tomohiro,

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

url:
https://github.com/0day-ci/linux/commits/Tomohiro-Yoshidomi/Input-psxpad-spi-Add-PlayStation-1-2-joypads-via-SPI-interface-Driver/20170430-114033
base:   https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   drivers/input/joystick/psxpad-spi.c: In function 'psxpad_spi_probe':
>> drivers/input/joystick/psxpad-spi.c:319:3: warning: 'err' may be used 
>> uninitialized in this function [-Wmaybe-uninitialized]
  dev_err(>dev,
  ^~
   "%s: failed to pdev alloc mode: %d\n",
   ~~
   __func__, err);
   ~~

vim +/err +319 drivers/input/joystick/psxpad-spi.c

   303  return 0;
   304  }
   305  #endif  /* CONFIG_JOYSTICK_PSXPAD_SPI_FF */
   306  
   307  static int psxpad_spi_probe(struct spi_device *spi)
   308  {
   309  struct psxpad *pad;
   310  struct input_polled_dev *pdev;
   311  struct input_dev *idev;
   312  int err;
   313  
   314  pad = devm_kzalloc(>dev, sizeof(struct psxpad), 
GFP_KERNEL);
   315  if (!pad)
   316  return -ENOMEM;
   317  pdev = input_allocate_polled_device();
   318  if (!pdev) {
 > 319  dev_err(>dev,
   320  "%s: failed to pdev alloc mode: %d\n",
   321  __func__, err);
   322  return -ENOMEM;
   323  }
   324  
   325  /* input poll device settings */
   326  pad->pdev = pdev;
   327  pad->spi = spi;

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


.config.gz
Description: application/gzip

Re: [PATCH v6] Input: psxpad-spi - Add PlayStation 1/2 joypads via SPI interface Driver

[kbuild test robot]

Hi Tomohiro,

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

url:
https://github.com/0day-ci/linux/commits/Tomohiro-Yoshidomi/Input-psxpad-spi-Add-PlayStation-1-2-joypads-via-SPI-interface-Driver/20170430-114033
base:   https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   drivers/input/joystick/psxpad-spi.c: In function 'psxpad_spi_probe':
>> drivers/input/joystick/psxpad-spi.c:319:3: warning: 'err' may be used 
>> uninitialized in this function [-Wmaybe-uninitialized]
  dev_err(>dev,
  ^~
   "%s: failed to pdev alloc mode: %d\n",
   ~~
   __func__, err);
   ~~

vim +/err +319 drivers/input/joystick/psxpad-spi.c

   303  return 0;
   304  }
   305  #endif  /* CONFIG_JOYSTICK_PSXPAD_SPI_FF */
   306  
   307  static int psxpad_spi_probe(struct spi_device *spi)
   308  {
   309  struct psxpad *pad;
   310  struct input_polled_dev *pdev;
   311  struct input_dev *idev;
   312  int err;
   313  
   314  pad = devm_kzalloc(>dev, sizeof(struct psxpad), 
GFP_KERNEL);
   315  if (!pad)
   316  return -ENOMEM;
   317  pdev = input_allocate_polled_device();
   318  if (!pdev) {
 > 319  dev_err(>dev,
   320  "%s: failed to pdev alloc mode: %d\n",
   321  __func__, err);
   322  return -ENOMEM;
   323  }
   324  
   325  /* input poll device settings */
   326  pad->pdev = pdev;
   327  pad->spi = spi;

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


.config.gz
Description: application/gzip

Re: [patch] timer: Fix timers_update_migration(), and call it in tmigr_init()

[Paul E. McKenney]

On Sun, Apr 30, 2017 at 03:21:58AM +0200, Mike Galbraith wrote:
> On Sat, 2017-04-29 at 14:45 -0700, Paul E. McKenney wrote:
> > On Sat, Apr 29, 2017 at 08:20:33PM +0200, Mike Galbraith wrote:
> > > On Sat, 2017-04-29 at 11:06 -0700, Paul E. McKenney wrote:
> > > 
> > > > If someone will either repost a fresh series or point me at exactly
> > > > the set of patches to use, I will run it through rcutorture again.
> > > 
> > > Patchlet is against x86-tip/master.today.
> > 
> > So today's (as in Saturday April 29) x86-tip/master with the following
> > patch applied?
> 
> Yeah.

OK, will fire it up once the current set of overnight tests complete.

Thanx, Paul

Re: [patch] timer: Fix timers_update_migration(), and call it in tmigr_init()

[Paul E. McKenney]

On Sun, Apr 30, 2017 at 03:21:58AM +0200, Mike Galbraith wrote:
> On Sat, 2017-04-29 at 14:45 -0700, Paul E. McKenney wrote:
> > On Sat, Apr 29, 2017 at 08:20:33PM +0200, Mike Galbraith wrote:
> > > On Sat, 2017-04-29 at 11:06 -0700, Paul E. McKenney wrote:
> > > 
> > > > If someone will either repost a fresh series or point me at exactly
> > > > the set of patches to use, I will run it through rcutorture again.
> > > 
> > > Patchlet is against x86-tip/master.today.
> > 
> > So today's (as in Saturday April 29) x86-tip/master with the following
> > patch applied?
> 
> Yeah.

OK, will fire it up once the current set of overnight tests complete.

Thanx, Paul

Re: Updating kernel.org cross compilers?

[Guenter Roeck]

On 04/26/2017 07:14 AM, Andre Przywara wrote:

Hi!

(Tony: I've seen you redirecting to "Chris" in an older email, but the
web archive doesn't have his email address)

It seems that many people (even outside the Linux kernel community) use
the cross compilers provided at kernel.org/pub/tools/crosstool.
The latest compiler I find there is 4.9.0, which celebrated its third
birthday at the weekend, also has been superseded by 4.9.4 meanwhile.

So I took Segher's buildall scripts from [1] and threw binutils 2.28 and
GCC 6.3.0 at them. After removing --enable-sjlj-exceptions from
build-gcc and adding --disable-multilib (for building x86-64 on a x86-64
box without 32-bit libs) I was able to build (bare-metal) toolchains for
all architectures except arc, m68k, tilegx and tilepro.
Now my understanding is that a baremetal/stage 1 compiler should be
build with "all-gcc" instead of the implicit "all" make target, and
"install-gcc" instead of "install". And indeed adding this to build-gcc
makes all toolchains build now - except arc, which needs an explicit
"--with-cpu=arc700" on the GCC configure command line.

So after those changes, the sequence:
$ ./buildall --toolchain
$ PATH=$PATH:/opt/cross/bin
$ ./buildall --kernel
worked reasonably well for me (binutils 2.28, GCC 6.3.0, Linux 4.11-rc8
on an Intel host with Ubuntu 14.04.5). Just tilegx/pro is still broken
due to toolchain issues.


Those need libgcc, and to build libgcc you'll have to install the kernel
header files. Same is true for cris (and possibly others).

Also, crisv32 builds as well.


So I wonder what the process is to get those compilers updated?


If you find out let me know.

Guenter


And what is a good build setup, so that the binaries run on as many
systems as possible?

Also the web page (https://www.kernel.org/pub/tools/crosstool) seems to
only link outdated builds (4.6.3, mostly), is that on purpose?

Cheers,
Andre.

[1] http://git.infradead.org/users/segher/buildall.git/

Re: Updating kernel.org cross compilers?

[Guenter Roeck]

On 04/26/2017 07:14 AM, Andre Przywara wrote:

Hi!

(Tony: I've seen you redirecting to "Chris" in an older email, but the
web archive doesn't have his email address)

It seems that many people (even outside the Linux kernel community) use
the cross compilers provided at kernel.org/pub/tools/crosstool.
The latest compiler I find there is 4.9.0, which celebrated its third
birthday at the weekend, also has been superseded by 4.9.4 meanwhile.

So I took Segher's buildall scripts from [1] and threw binutils 2.28 and
GCC 6.3.0 at them. After removing --enable-sjlj-exceptions from
build-gcc and adding --disable-multilib (for building x86-64 on a x86-64
box without 32-bit libs) I was able to build (bare-metal) toolchains for
all architectures except arc, m68k, tilegx and tilepro.
Now my understanding is that a baremetal/stage 1 compiler should be
build with "all-gcc" instead of the implicit "all" make target, and
"install-gcc" instead of "install". And indeed adding this to build-gcc
makes all toolchains build now - except arc, which needs an explicit
"--with-cpu=arc700" on the GCC configure command line.

So after those changes, the sequence:
$ ./buildall --toolchain
$ PATH=$PATH:/opt/cross/bin
$ ./buildall --kernel
worked reasonably well for me (binutils 2.28, GCC 6.3.0, Linux 4.11-rc8
on an Intel host with Ubuntu 14.04.5). Just tilegx/pro is still broken
due to toolchain issues.


Those need libgcc, and to build libgcc you'll have to install the kernel
header files. Same is true for cris (and possibly others).

Also, crisv32 builds as well.


So I wonder what the process is to get those compilers updated?


If you find out let me know.

Guenter


And what is a good build setup, so that the binaries run on as many
systems as possible?

Also the web page (https://www.kernel.org/pub/tools/crosstool) seems to
only link outdated builds (4.6.3, mostly), is that on purpose?

Cheers,
Andre.

[1] http://git.infradead.org/users/segher/buildall.git/

Re: [PATCH v6] Input: psxpad-spi - Add PlayStation 1/2 joypads via SPI interface Driver

[Tomohiro Yoshidomi]

Mr.Torokhov

I fixed source, and sent PATCH v6 to you.

As Mr.Nocera said, I fixed souces does not use 'PSX' in sentences.
Also, I wrote that a separate power supply is required for the motor.

2017-04-30 3:16 GMT+09:00 Dmitry Torokhov :
> Hi,
>
> On Sat, Apr 29, 2017 at 06:40:53PM +0900, Tomohiro Yoshidomi wrote:
>> PSX pads can be connected directly to the SPI bus.
>>
>> Signed-off-by: Tomohiro Yoshidomi 
>
> Thank you very much for making requested changes and your patience. I
> think we just need a few finishing touches and we can commit this
> driver.
>
>> ---
>>  drivers/input/joystick/Kconfig  |  17 ++
>>  drivers/input/joystick/Makefile |   1 +
>>  drivers/input/joystick/psxpad-spi.c | 387 
>> 
>>  3 files changed, 405 insertions(+)
>>  create mode 100644 drivers/input/joystick/psxpad-spi.c
>>
>> diff --git a/drivers/input/joystick/Kconfig b/drivers/input/joystick/Kconfig
>> index 4215b538..bfbda643 100644
>> --- a/drivers/input/joystick/Kconfig
>> +++ b/drivers/input/joystick/Kconfig
>> @@ -330,4 +330,21 @@ config JOYSTICK_MAPLE
>> To compile this as a module choose M here: the module will be called
>> maplecontrol.
>>
>> +config JOYSTICK_PSXPAD_SPI
>> + tristate "PSX (Play Station 1/2) pad with SPI Bus Driver"
>
> Let's call this "PSX (Play Station 1/2) gamepad on SPI bus"

Fixed.
"PlayStation 1/2 joypads via SPI interface"

>> + depends on SPI
>> + select INPUT_POLLDEV
>> + help
>> +   Say Y here if you connect PSX (PS1/2) pad with SPI Interface.
>
> "Say Y here if you wish to connect PSX (PS1/2) pad via SPI interface."

Fixed.
"Say Y here if you wish to connect PlayStation 1/2 joypads via SPI interface."

>> +
>> +   To compile this driver as a module, choose M here: the
>> +   module will be called psxpad-spi.
>> +
>> +config JOYSTICK_PSXPAD_SPI_FF
>> + bool "PSX pad with SPI Bus rumble support"
>
> Let's call it "PSX gamepad force feedback (rumble) support"

Fixed.
"PlayStation 1/2 joypads force feedback (rumble) support"

>> + depends on JOYSTICK_PSXPAD_SPI
>> + select INPUT_FF_MEMLESS
>> + help
>> +   Say Y here if you want to take advantage of PSX pad rumble features.
>> +
>>  endif
>> diff --git a/drivers/input/joystick/Makefile 
>> b/drivers/input/joystick/Makefile
>> index 92dc0de9..496fd56b 100644
>> --- a/drivers/input/joystick/Makefile
>> +++ b/drivers/input/joystick/Makefile
>> @@ -21,6 +21,7 @@ obj-$(CONFIG_JOYSTICK_INTERACT) += interact.o
>>  obj-$(CONFIG_JOYSTICK_JOYDUMP)   += joydump.o
>>  obj-$(CONFIG_JOYSTICK_MAGELLAN)  += magellan.o
>>  obj-$(CONFIG_JOYSTICK_MAPLE) += maplecontrol.o
>> +obj-$(CONFIG_JOYSTICK_PSXPAD_SPI)+= psxpad-spi.o
>>  obj-$(CONFIG_JOYSTICK_SIDEWINDER)+= sidewinder.o
>>  obj-$(CONFIG_JOYSTICK_SPACEBALL) += spaceball.o
>>  obj-$(CONFIG_JOYSTICK_SPACEORB)  += spaceorb.o
>> diff --git a/drivers/input/joystick/psxpad-spi.c 
>> b/drivers/input/joystick/psxpad-spi.c
>> new file mode 100644
>> index ..9684839c
>> --- /dev/null
>> +++ b/drivers/input/joystick/psxpad-spi.c
>> @@ -0,0 +1,387 @@
>> +/*
>> + * PSX (Play Station 1/2) pad (SPI Interface)
>> + *
>> + * Copyright (C) 2017 Tomohiro Yoshidomi 
>> + * Licensed under the GPL-2 or later.
>> + *
>> + * PSX pad plug (not socket)
>> + *  123 456 789
>> + * (...|...|...)
>> + *
>> + * 1: DAT -> MISO (pullup with 1k owm to 3.3V)
>> + * 2: CMD -> MOSI
>> + * 3: 9V (for motor, if not use N.C.)
>> + * 4: GND
>> + * 5: 3.3V
>> + * 6: Attention -> CS(SS)
>> + * 7: SCK -> SCK
>> + * 8: N.C.
>> + * 9: ACK -> N.C.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define REVERSE_BIT(x) x) & 0x80) >> 7) | (((x) & 0x40) >> 5) | (((x) & 
>> 0x20) >> 3) | (((x) & 0x10) >> 1) | (((x) & 0x08) << 1) | (((x) & 0x04) << 
>> 3) | (((x) & 0x02) << 5) | (((x) & 0x01) << 7))
>> +
>> +static const u8 PSX_CMD_POLL[]   = {0x01, 0x42, 0x00, 0x00, 
>> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
>> 0x00, 0x00, 0x00, 0x00, 0x00};
>> +static const u8 PSX_CMD_ENTER_CFG[]  = {0x01, 0x43, 0x00, 0x01, 0x00, 0x00, 
>> 0x00, 0x00, 0x00};
>> +static const u8 PSX_CMD_EXIT_CFG[]   = {0x01, 0x43, 0x00, 0x00, 0x5A, 0x5A, 
>> 0x5A, 0x5A, 0x5A};
>> +static const u8 PSX_CMD_ENABLE_MOTOR[]   = {0x01, 0x4D, 0x00, 0xFF, 
>> 0xFF, 0xFF, 0xFF, 0xFF, 0xFF};
>> +
>> +struct psxpad {
>> + struct spi_device *spi;
>> + struct input_polled_dev *pdev;
>> + struct input_dev *idev;
>> + char phys[0x20];
>> + bool motor1enable;
>> + bool motor2enable;
>> + u8 motor1level;
>> + u8 motor2level;
>> + u8 pollcmd[sizeof(PSX_CMD_POLL)];
>> + u8 enablemotor[sizeof(PSX_CMD_ENABLE_MOTOR)];
>> + u8 sendbuf[0x20] cacheline_aligned;
>> + u8 

Re: [PATCH v6] Input: psxpad-spi - Add PlayStation 1/2 joypads via SPI interface Driver

[Tomohiro Yoshidomi]

Mr.Torokhov

I fixed source, and sent PATCH v6 to you.

As Mr.Nocera said, I fixed souces does not use 'PSX' in sentences.
Also, I wrote that a separate power supply is required for the motor.

2017-04-30 3:16 GMT+09:00 Dmitry Torokhov :
> Hi,
>
> On Sat, Apr 29, 2017 at 06:40:53PM +0900, Tomohiro Yoshidomi wrote:
>> PSX pads can be connected directly to the SPI bus.
>>
>> Signed-off-by: Tomohiro Yoshidomi 
>
> Thank you very much for making requested changes and your patience. I
> think we just need a few finishing touches and we can commit this
> driver.
>
>> ---
>>  drivers/input/joystick/Kconfig  |  17 ++
>>  drivers/input/joystick/Makefile |   1 +
>>  drivers/input/joystick/psxpad-spi.c | 387 
>> 
>>  3 files changed, 405 insertions(+)
>>  create mode 100644 drivers/input/joystick/psxpad-spi.c
>>
>> diff --git a/drivers/input/joystick/Kconfig b/drivers/input/joystick/Kconfig
>> index 4215b538..bfbda643 100644
>> --- a/drivers/input/joystick/Kconfig
>> +++ b/drivers/input/joystick/Kconfig
>> @@ -330,4 +330,21 @@ config JOYSTICK_MAPLE
>> To compile this as a module choose M here: the module will be called
>> maplecontrol.
>>
>> +config JOYSTICK_PSXPAD_SPI
>> + tristate "PSX (Play Station 1/2) pad with SPI Bus Driver"
>
> Let's call this "PSX (Play Station 1/2) gamepad on SPI bus"

Fixed.
"PlayStation 1/2 joypads via SPI interface"

>> + depends on SPI
>> + select INPUT_POLLDEV
>> + help
>> +   Say Y here if you connect PSX (PS1/2) pad with SPI Interface.
>
> "Say Y here if you wish to connect PSX (PS1/2) pad via SPI interface."

Fixed.
"Say Y here if you wish to connect PlayStation 1/2 joypads via SPI interface."

>> +
>> +   To compile this driver as a module, choose M here: the
>> +   module will be called psxpad-spi.
>> +
>> +config JOYSTICK_PSXPAD_SPI_FF
>> + bool "PSX pad with SPI Bus rumble support"
>
> Let's call it "PSX gamepad force feedback (rumble) support"

Fixed.
"PlayStation 1/2 joypads force feedback (rumble) support"

>> + depends on JOYSTICK_PSXPAD_SPI
>> + select INPUT_FF_MEMLESS
>> + help
>> +   Say Y here if you want to take advantage of PSX pad rumble features.
>> +
>>  endif
>> diff --git a/drivers/input/joystick/Makefile 
>> b/drivers/input/joystick/Makefile
>> index 92dc0de9..496fd56b 100644
>> --- a/drivers/input/joystick/Makefile
>> +++ b/drivers/input/joystick/Makefile
>> @@ -21,6 +21,7 @@ obj-$(CONFIG_JOYSTICK_INTERACT) += interact.o
>>  obj-$(CONFIG_JOYSTICK_JOYDUMP)   += joydump.o
>>  obj-$(CONFIG_JOYSTICK_MAGELLAN)  += magellan.o
>>  obj-$(CONFIG_JOYSTICK_MAPLE) += maplecontrol.o
>> +obj-$(CONFIG_JOYSTICK_PSXPAD_SPI)+= psxpad-spi.o
>>  obj-$(CONFIG_JOYSTICK_SIDEWINDER)+= sidewinder.o
>>  obj-$(CONFIG_JOYSTICK_SPACEBALL) += spaceball.o
>>  obj-$(CONFIG_JOYSTICK_SPACEORB)  += spaceorb.o
>> diff --git a/drivers/input/joystick/psxpad-spi.c 
>> b/drivers/input/joystick/psxpad-spi.c
>> new file mode 100644
>> index ..9684839c
>> --- /dev/null
>> +++ b/drivers/input/joystick/psxpad-spi.c
>> @@ -0,0 +1,387 @@
>> +/*
>> + * PSX (Play Station 1/2) pad (SPI Interface)
>> + *
>> + * Copyright (C) 2017 Tomohiro Yoshidomi 
>> + * Licensed under the GPL-2 or later.
>> + *
>> + * PSX pad plug (not socket)
>> + *  123 456 789
>> + * (...|...|...)
>> + *
>> + * 1: DAT -> MISO (pullup with 1k owm to 3.3V)
>> + * 2: CMD -> MOSI
>> + * 3: 9V (for motor, if not use N.C.)
>> + * 4: GND
>> + * 5: 3.3V
>> + * 6: Attention -> CS(SS)
>> + * 7: SCK -> SCK
>> + * 8: N.C.
>> + * 9: ACK -> N.C.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define REVERSE_BIT(x) x) & 0x80) >> 7) | (((x) & 0x40) >> 5) | (((x) & 
>> 0x20) >> 3) | (((x) & 0x10) >> 1) | (((x) & 0x08) << 1) | (((x) & 0x04) << 
>> 3) | (((x) & 0x02) << 5) | (((x) & 0x01) << 7))
>> +
>> +static const u8 PSX_CMD_POLL[]   = {0x01, 0x42, 0x00, 0x00, 
>> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
>> 0x00, 0x00, 0x00, 0x00, 0x00};
>> +static const u8 PSX_CMD_ENTER_CFG[]  = {0x01, 0x43, 0x00, 0x01, 0x00, 0x00, 
>> 0x00, 0x00, 0x00};
>> +static const u8 PSX_CMD_EXIT_CFG[]   = {0x01, 0x43, 0x00, 0x00, 0x5A, 0x5A, 
>> 0x5A, 0x5A, 0x5A};
>> +static const u8 PSX_CMD_ENABLE_MOTOR[]   = {0x01, 0x4D, 0x00, 0xFF, 
>> 0xFF, 0xFF, 0xFF, 0xFF, 0xFF};
>> +
>> +struct psxpad {
>> + struct spi_device *spi;
>> + struct input_polled_dev *pdev;
>> + struct input_dev *idev;
>> + char phys[0x20];
>> + bool motor1enable;
>> + bool motor2enable;
>> + u8 motor1level;
>> + u8 motor2level;
>> + u8 pollcmd[sizeof(PSX_CMD_POLL)];
>> + u8 enablemotor[sizeof(PSX_CMD_ENABLE_MOTOR)];
>> + u8 sendbuf[0x20] cacheline_aligned;
>> + u8 response[sizeof(PSX_CMD_POLL)] cacheline_aligned;
>> +};
>> +

[PATCH v6] Input: psxpad-spi - Add PlayStation 1/2 joypads via SPI interface Driver

[Tomohiro Yoshidomi]

PlayStation 1/2 joypads can be connected directly to the SPI interface.

Signed-off-by: Tomohiro Yoshidomi 
---
 drivers/input/joystick/Kconfig  |  22 ++
 drivers/input/joystick/Makefile |   1 +
 drivers/input/joystick/psxpad-spi.c | 433 
 3 files changed, 456 insertions(+)
 create mode 100644 drivers/input/joystick/psxpad-spi.c

diff --git a/drivers/input/joystick/Kconfig b/drivers/input/joystick/Kconfig
index 4215b538..cbcb9a6e 100644
--- a/drivers/input/joystick/Kconfig
+++ b/drivers/input/joystick/Kconfig
@@ -330,4 +330,26 @@ config JOYSTICK_MAPLE
  To compile this as a module choose M here: the module will be called
  maplecontrol.
 
+config JOYSTICK_PSXPAD_SPI
+   tristate "PlayStation 1/2 joypads via SPI interface"
+   depends on SPI
+   select INPUT_POLLDEV
+   help
+ Say Y here if you wish to connect PlayStation 1/2 joypads
+ via SPI interface.
+
+ To compile this driver as a module, choose M here: the
+ module will be called psxpad-spi.
+
+config JOYSTICK_PSXPAD_SPI_FF
+   bool "PlayStation 1/2 joypads force feedback (rumble) support"
+   depends on JOYSTICK_PSXPAD_SPI
+   select INPUT_FF_MEMLESS
+   help
+ Say Y here if you want to take advantage of
+ PlayStation 1/2 joypads rumble features.
+
+ To drive rumble motor,
+ a dedicated power supply is required.
+
 endif
diff --git a/drivers/input/joystick/Makefile b/drivers/input/joystick/Makefile
index 92dc0de9..496fd56b 100644
--- a/drivers/input/joystick/Makefile
+++ b/drivers/input/joystick/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_JOYSTICK_INTERACT)   += interact.o
 obj-$(CONFIG_JOYSTICK_JOYDUMP) += joydump.o
 obj-$(CONFIG_JOYSTICK_MAGELLAN)+= magellan.o
 obj-$(CONFIG_JOYSTICK_MAPLE)   += maplecontrol.o
+obj-$(CONFIG_JOYSTICK_PSXPAD_SPI)  += psxpad-spi.o
 obj-$(CONFIG_JOYSTICK_SIDEWINDER)  += sidewinder.o
 obj-$(CONFIG_JOYSTICK_SPACEBALL)   += spaceball.o
 obj-$(CONFIG_JOYSTICK_SPACEORB)+= spaceorb.o
diff --git a/drivers/input/joystick/psxpad-spi.c 
b/drivers/input/joystick/psxpad-spi.c
new file mode 100644
index ..d3eb0854
--- /dev/null
+++ b/drivers/input/joystick/psxpad-spi.c
@@ -0,0 +1,433 @@
+/*
+ * PlayStation 1/2 joypads via SPI interface Driver
+ *
+ * Copyright (C) 2017 Tomohiro Yoshidomi 
+ * Licensed under the GPL-2 or later.
+ *
+ * PlayStation 1/2 joypad's plug (not socket)
+ *  123 456 789
+ * (...|...|...)
+ *
+ * 1: DAT -> MISO (pullup with 1k owm to 3.3V)
+ * 2: CMD -> MOSI
+ * 3: 9V (for motor, if not use N.C.)
+ * 4: GND
+ * 5: 3.3V
+ * 6: Attention -> CS(SS)
+ * 7: SCK -> SCK
+ * 8: N.C.
+ * 9: ACK -> N.C.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define REVERSE_BIT(x) x) & 0x80) >> 7) | (((x) & 0x40) >> 5) | \
+   (((x) & 0x20) >> 3) | (((x) & 0x10) >> 1) | (((x) & 0x08) << 1) | \
+   (((x) & 0x04) << 3) | (((x) & 0x02) << 5) | (((x) & 0x01) << 7))
+
+/* PlayStation 1/2 joypad command and response are LSBFIRST. */
+
+/* 0x01, 0x42, 0x00, 0x00, 0x00,
+ * 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ * 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
+ */
+static const u8 PSX_CMD_POLL[] = {
+   0x80, 0x42, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
+};
+/* 0x01, 0x43, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00 */
+static const u8 PSX_CMD_ENTER_CFG[] = {
+   0x80, 0xC2, 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00
+};
+/* 0x01, 0x43, 0x00, 0x00, 0x5A, 0x5A, 0x5A, 0x5A, 0x5A */
+static const u8 PSX_CMD_EXIT_CFG[] = {
+   0x80, 0xC2, 0x00, 0x00, 0x5A, 0x5A, 0x5A, 0x5A, 0x5A
+};
+/* 0x01, 0x4D, 0x00, 0x00, 0x01, 0xFF, 0xFF, 0xFF, 0xFF */
+static const u8 PSX_CMD_ENABLE_MOTOR[] = {
+   0x80, 0xB2, 0x00, 0x00, 0x80, 0xFF, 0xFF, 0xFF, 0xFF
+};
+
+struct psxpad {
+   struct spi_device *spi;
+   struct input_polled_dev *pdev;
+   struct input_dev *idev;
+   char phys[0x20];
+   bool motor1enable;
+   bool motor2enable;
+   u8 motor1level;
+   u8 motor2level;
+   u8 sendbuf[0x20] cacheline_aligned;
+   u8 response[sizeof(PSX_CMD_POLL)] cacheline_aligned;
+};
+
+static int psxpad_command(struct psxpad *pad, const u8 sendcmdlen)
+{
+   struct spi_transfer xfers = {
+   .tx_buf = pad->sendbuf,
+   .rx_buf = pad->response,
+   .len= sendcmdlen,
+   };
+   int err;
+
+   err = spi_sync_transfer(pad->spi, , 1);
+   if (err) {
+   dev_err(>spi->dev,
+   "%s: failed to SPI xfers mode: %d\n",
+   __func__, err);
+   return err;
+   }
+
+   return 0;
+}
+
+#ifdef 

[PATCH v6] Input: psxpad-spi - Add PlayStation 1/2 joypads via SPI interface Driver

[Tomohiro Yoshidomi]

PlayStation 1/2 joypads can be connected directly to the SPI interface.

Signed-off-by: Tomohiro Yoshidomi 
---
 drivers/input/joystick/Kconfig  |  22 ++
 drivers/input/joystick/Makefile |   1 +
 drivers/input/joystick/psxpad-spi.c | 433 
 3 files changed, 456 insertions(+)
 create mode 100644 drivers/input/joystick/psxpad-spi.c

diff --git a/drivers/input/joystick/Kconfig b/drivers/input/joystick/Kconfig
index 4215b538..cbcb9a6e 100644
--- a/drivers/input/joystick/Kconfig
+++ b/drivers/input/joystick/Kconfig
@@ -330,4 +330,26 @@ config JOYSTICK_MAPLE
  To compile this as a module choose M here: the module will be called
  maplecontrol.
 
+config JOYSTICK_PSXPAD_SPI
+   tristate "PlayStation 1/2 joypads via SPI interface"
+   depends on SPI
+   select INPUT_POLLDEV
+   help
+ Say Y here if you wish to connect PlayStation 1/2 joypads
+ via SPI interface.
+
+ To compile this driver as a module, choose M here: the
+ module will be called psxpad-spi.
+
+config JOYSTICK_PSXPAD_SPI_FF
+   bool "PlayStation 1/2 joypads force feedback (rumble) support"
+   depends on JOYSTICK_PSXPAD_SPI
+   select INPUT_FF_MEMLESS
+   help
+ Say Y here if you want to take advantage of
+ PlayStation 1/2 joypads rumble features.
+
+ To drive rumble motor,
+ a dedicated power supply is required.
+
 endif
diff --git a/drivers/input/joystick/Makefile b/drivers/input/joystick/Makefile
index 92dc0de9..496fd56b 100644
--- a/drivers/input/joystick/Makefile
+++ b/drivers/input/joystick/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_JOYSTICK_INTERACT)   += interact.o
 obj-$(CONFIG_JOYSTICK_JOYDUMP) += joydump.o
 obj-$(CONFIG_JOYSTICK_MAGELLAN)+= magellan.o
 obj-$(CONFIG_JOYSTICK_MAPLE)   += maplecontrol.o
+obj-$(CONFIG_JOYSTICK_PSXPAD_SPI)  += psxpad-spi.o
 obj-$(CONFIG_JOYSTICK_SIDEWINDER)  += sidewinder.o
 obj-$(CONFIG_JOYSTICK_SPACEBALL)   += spaceball.o
 obj-$(CONFIG_JOYSTICK_SPACEORB)+= spaceorb.o
diff --git a/drivers/input/joystick/psxpad-spi.c 
b/drivers/input/joystick/psxpad-spi.c
new file mode 100644
index ..d3eb0854
--- /dev/null
+++ b/drivers/input/joystick/psxpad-spi.c
@@ -0,0 +1,433 @@
+/*
+ * PlayStation 1/2 joypads via SPI interface Driver
+ *
+ * Copyright (C) 2017 Tomohiro Yoshidomi 
+ * Licensed under the GPL-2 or later.
+ *
+ * PlayStation 1/2 joypad's plug (not socket)
+ *  123 456 789
+ * (...|...|...)
+ *
+ * 1: DAT -> MISO (pullup with 1k owm to 3.3V)
+ * 2: CMD -> MOSI
+ * 3: 9V (for motor, if not use N.C.)
+ * 4: GND
+ * 5: 3.3V
+ * 6: Attention -> CS(SS)
+ * 7: SCK -> SCK
+ * 8: N.C.
+ * 9: ACK -> N.C.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define REVERSE_BIT(x) x) & 0x80) >> 7) | (((x) & 0x40) >> 5) | \
+   (((x) & 0x20) >> 3) | (((x) & 0x10) >> 1) | (((x) & 0x08) << 1) | \
+   (((x) & 0x04) << 3) | (((x) & 0x02) << 5) | (((x) & 0x01) << 7))
+
+/* PlayStation 1/2 joypad command and response are LSBFIRST. */
+
+/* 0x01, 0x42, 0x00, 0x00, 0x00,
+ * 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ * 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
+ */
+static const u8 PSX_CMD_POLL[] = {
+   0x80, 0x42, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
+};
+/* 0x01, 0x43, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00 */
+static const u8 PSX_CMD_ENTER_CFG[] = {
+   0x80, 0xC2, 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00
+};
+/* 0x01, 0x43, 0x00, 0x00, 0x5A, 0x5A, 0x5A, 0x5A, 0x5A */
+static const u8 PSX_CMD_EXIT_CFG[] = {
+   0x80, 0xC2, 0x00, 0x00, 0x5A, 0x5A, 0x5A, 0x5A, 0x5A
+};
+/* 0x01, 0x4D, 0x00, 0x00, 0x01, 0xFF, 0xFF, 0xFF, 0xFF */
+static const u8 PSX_CMD_ENABLE_MOTOR[] = {
+   0x80, 0xB2, 0x00, 0x00, 0x80, 0xFF, 0xFF, 0xFF, 0xFF
+};
+
+struct psxpad {
+   struct spi_device *spi;
+   struct input_polled_dev *pdev;
+   struct input_dev *idev;
+   char phys[0x20];
+   bool motor1enable;
+   bool motor2enable;
+   u8 motor1level;
+   u8 motor2level;
+   u8 sendbuf[0x20] cacheline_aligned;
+   u8 response[sizeof(PSX_CMD_POLL)] cacheline_aligned;
+};
+
+static int psxpad_command(struct psxpad *pad, const u8 sendcmdlen)
+{
+   struct spi_transfer xfers = {
+   .tx_buf = pad->sendbuf,
+   .rx_buf = pad->response,
+   .len= sendcmdlen,
+   };
+   int err;
+
+   err = spi_sync_transfer(pad->spi, , 1);
+   if (err) {
+   dev_err(>spi->dev,
+   "%s: failed to SPI xfers mode: %d\n",
+   __func__, err);
+   return err;
+   }
+
+   return 0;
+}
+
+#ifdef CONFIG_JOYSTICK_PSXPAD_SPI_FF
+static void 

Re: [rcu:dev.2017.04.28a 41/45] include/linux/notifier.h:77:21: error: field 'srcu' has incomplete type

[Paul E. McKenney]

On Sun, Apr 30, 2017 at 07:32:17AM +0800, kbuild test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
> dev.2017.04.28a
> head:   1205059ca5d4835e9213ff943ce3a51980718b5d
> commit: e01ef0529ed548c1b30206058c2b5eecbbc07998 [41/45] srcu: Make SRCU be 
> once again optional
> config: sparc64-allnoconfig (attached as .config)
> compiler: sparc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
> wget 
> https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout e01ef0529ed548c1b30206058c2b5eecbbc07998
> # save the attached .config to linux build tree
> make.cross ARCH=sparc64 
> 
> All errors (new ones prefixed by >>):
> 
>In file included from include/linux/memory_hotplug.h:6:0,
> from include/linux/mmzone.h:749,
> from include/linux/gfp.h:5,
> from include/linux/kmod.h:22,
> from include/linux/module.h:13,
> from init/main.c:16:
> >> include/linux/notifier.h:77:21: error: field 'srcu' has incomplete type
>  struct srcu_struct srcu;
> ^~~~

Hmmm...

This sort of thing has been legal for quite some time, so I am taking
the crude step of providing an empty definition for srcu_struct when
building with CONFIG_SRCU=n.

Thanx, Paul

> vim +/srcu +77 include/linux/notifier.h
> 
> e041c6834 Alan Stern2006-03-27  61  struct atomic_notifier_head {
> e041c6834 Alan Stern2006-03-27  62spinlock_t lock;
> 374a8e0dc Arnd Bergmann 2010-02-24  63struct notifier_block __rcu 
> *head;
> e041c6834 Alan Stern2006-03-27  64  };
> e041c6834 Alan Stern2006-03-27  65  
> e041c6834 Alan Stern2006-03-27  66  struct blocking_notifier_head {
> e041c6834 Alan Stern2006-03-27  67struct rw_semaphore rwsem;
> 374a8e0dc Arnd Bergmann 2010-02-24  68struct notifier_block __rcu 
> *head;
> e041c6834 Alan Stern2006-03-27  69  };
> e041c6834 Alan Stern2006-03-27  70  
> e041c6834 Alan Stern2006-03-27  71  struct raw_notifier_head {
> 374a8e0dc Arnd Bergmann 2010-02-24  72struct notifier_block __rcu 
> *head;
> e041c6834 Alan Stern2006-03-27  73  };
> e041c6834 Alan Stern2006-03-27  74  
> eabc06940 Alan Stern2006-10-04  75  struct srcu_notifier_head {
> eabc06940 Alan Stern2006-10-04  76struct mutex mutex;
> eabc06940 Alan Stern2006-10-04 @77struct srcu_struct srcu;
> 374a8e0dc Arnd Bergmann 2010-02-24  78struct notifier_block __rcu 
> *head;
> eabc06940 Alan Stern2006-10-04  79  };
> eabc06940 Alan Stern2006-10-04  80  
> e041c6834 Alan Stern2006-03-27  81  #define 
> ATOMIC_INIT_NOTIFIER_HEAD(name) do {  \
> e041c6834 Alan Stern2006-03-27  82
> spin_lock_init(&(name)->lock);  \
> e041c6834 Alan Stern2006-03-27  83(name)->head = NULL;
> \
> e041c6834 Alan Stern2006-03-27  84} while (0)
> e041c6834 Alan Stern2006-03-27  85  #define 
> BLOCKING_INIT_NOTIFIER_HEAD(name) do {\
> 
> :: The code at line 77 was first introduced by commit
> :: eabc069401bcf45bcc3f19e643017bf761780aa8 [PATCH] Add SRCU-based 
> notifier chains
> 
> :: TO: Alan Stern 
> :: CC: Linus Torvalds 
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Re: [rcu:dev.2017.04.28a 41/45] include/linux/notifier.h:77:21: error: field 'srcu' has incomplete type

[Paul E. McKenney]

On Sun, Apr 30, 2017 at 07:32:17AM +0800, kbuild test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
> dev.2017.04.28a
> head:   1205059ca5d4835e9213ff943ce3a51980718b5d
> commit: e01ef0529ed548c1b30206058c2b5eecbbc07998 [41/45] srcu: Make SRCU be 
> once again optional
> config: sparc64-allnoconfig (attached as .config)
> compiler: sparc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
> wget 
> https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout e01ef0529ed548c1b30206058c2b5eecbbc07998
> # save the attached .config to linux build tree
> make.cross ARCH=sparc64 
> 
> All errors (new ones prefixed by >>):
> 
>In file included from include/linux/memory_hotplug.h:6:0,
> from include/linux/mmzone.h:749,
> from include/linux/gfp.h:5,
> from include/linux/kmod.h:22,
> from include/linux/module.h:13,
> from init/main.c:16:
> >> include/linux/notifier.h:77:21: error: field 'srcu' has incomplete type
>  struct srcu_struct srcu;
> ^~~~

Hmmm...

This sort of thing has been legal for quite some time, so I am taking
the crude step of providing an empty definition for srcu_struct when
building with CONFIG_SRCU=n.

Thanx, Paul

> vim +/srcu +77 include/linux/notifier.h
> 
> e041c6834 Alan Stern2006-03-27  61  struct atomic_notifier_head {
> e041c6834 Alan Stern2006-03-27  62spinlock_t lock;
> 374a8e0dc Arnd Bergmann 2010-02-24  63struct notifier_block __rcu 
> *head;
> e041c6834 Alan Stern2006-03-27  64  };
> e041c6834 Alan Stern2006-03-27  65  
> e041c6834 Alan Stern2006-03-27  66  struct blocking_notifier_head {
> e041c6834 Alan Stern2006-03-27  67struct rw_semaphore rwsem;
> 374a8e0dc Arnd Bergmann 2010-02-24  68struct notifier_block __rcu 
> *head;
> e041c6834 Alan Stern2006-03-27  69  };
> e041c6834 Alan Stern2006-03-27  70  
> e041c6834 Alan Stern2006-03-27  71  struct raw_notifier_head {
> 374a8e0dc Arnd Bergmann 2010-02-24  72struct notifier_block __rcu 
> *head;
> e041c6834 Alan Stern2006-03-27  73  };
> e041c6834 Alan Stern2006-03-27  74  
> eabc06940 Alan Stern2006-10-04  75  struct srcu_notifier_head {
> eabc06940 Alan Stern2006-10-04  76struct mutex mutex;
> eabc06940 Alan Stern2006-10-04 @77struct srcu_struct srcu;
> 374a8e0dc Arnd Bergmann 2010-02-24  78struct notifier_block __rcu 
> *head;
> eabc06940 Alan Stern2006-10-04  79  };
> eabc06940 Alan Stern2006-10-04  80  
> e041c6834 Alan Stern2006-03-27  81  #define 
> ATOMIC_INIT_NOTIFIER_HEAD(name) do {  \
> e041c6834 Alan Stern2006-03-27  82
> spin_lock_init(&(name)->lock);  \
> e041c6834 Alan Stern2006-03-27  83(name)->head = NULL;
> \
> e041c6834 Alan Stern2006-03-27  84} while (0)
> e041c6834 Alan Stern2006-03-27  85  #define 
> BLOCKING_INIT_NOTIFIER_HEAD(name) do {\
> 
> :: The code at line 77 was first introduced by commit
> :: eabc069401bcf45bcc3f19e643017bf761780aa8 [PATCH] Add SRCU-based 
> notifier chains
> 
> :: TO: Alan Stern 
> :: CC: Linus Torvalds 
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Re: [PATCH v1] LSM: Enable multiple calls to security_add_hooks() for the same LSM

[Tetsuo Handa]

Casey Schaufler wrote:
> On 4/29/2017 12:02 PM, Mickael Salaun wrote:
> > Check if the registering LSM already registered hooks just before. This
> > enable to split hook declarations into multiple files without
> > registering multiple time the same LSM name, starting from commit
> > d69dece5f5b6 ("LSM: Add /sys/kernel/security/lsm").
> 
> What's special about the previous registration? Keep it
> simple and check it the name is already anywhere on the
> list and only add it if it's not already there. I don't
> see advantage to:
> 
>   % cat /sys/kernel/security/lsm
>   capability,yama,spiffy,selinux,spiffy
> 
> over
>   % cat /sys/kernel/security/lsm
>   capability,yama,spiffy,selinux
> 

-   if (lsm_append(lsm, _names) < 0)
+   if (lsm && lsm_append(lsm, _names) < 0)

in security_add_hooks()?

Re: [PATCH v1] LSM: Enable multiple calls to security_add_hooks() for the same LSM

[Tetsuo Handa]

Casey Schaufler wrote:
> On 4/29/2017 12:02 PM, Mickael Salaun wrote:
> > Check if the registering LSM already registered hooks just before. This
> > enable to split hook declarations into multiple files without
> > registering multiple time the same LSM name, starting from commit
> > d69dece5f5b6 ("LSM: Add /sys/kernel/security/lsm").
> 
> What's special about the previous registration? Keep it
> simple and check it the name is already anywhere on the
> list and only add it if it's not already there. I don't
> see advantage to:
> 
>   % cat /sys/kernel/security/lsm
>   capability,yama,spiffy,selinux,spiffy
> 
> over
>   % cat /sys/kernel/security/lsm
>   capability,yama,spiffy,selinux
> 

-   if (lsm_append(lsm, _names) < 0)
+   if (lsm && lsm_append(lsm, _names) < 0)

in security_add_hooks()?

Re: [patch] timer: Fix timers_update_migration(), and call it in tmigr_init()

[Mike Galbraith]

On Sat, 2017-04-29 at 14:45 -0700, Paul E. McKenney wrote:
> On Sat, Apr 29, 2017 at 08:20:33PM +0200, Mike Galbraith wrote:
> > On Sat, 2017-04-29 at 11:06 -0700, Paul E. McKenney wrote:
> > 
> > > If someone will either repost a fresh series or point me at exactly
> > > the set of patches to use, I will run it through rcutorture again.
> > 
> > Patchlet is against x86-tip/master.today.
> 
> So today's (as in Saturday April 29) x86-tip/master with the following
> patch applied?

Yeah.

Re: [patch] timer: Fix timers_update_migration(), and call it in tmigr_init()

[Mike Galbraith]

On Sat, 2017-04-29 at 14:45 -0700, Paul E. McKenney wrote:
> On Sat, Apr 29, 2017 at 08:20:33PM +0200, Mike Galbraith wrote:
> > On Sat, 2017-04-29 at 11:06 -0700, Paul E. McKenney wrote:
> > 
> > > If someone will either repost a fresh series or point me at exactly
> > > the set of patches to use, I will run it through rcutorture again.
> > 
> > Patchlet is against x86-tip/master.today.
> 
> So today's (as in Saturday April 29) x86-tip/master with the following
> patch applied?

Yeah.

Re: new ...at() flag: AT_NO_JUMPS

[Andy Lutomirski]

On Sat, Apr 29, 2017 at 4:25 PM, Al Viro  wrote:
> On Sat, Apr 29, 2017 at 04:17:18PM -0700, Andy Lutomirski wrote:
>> On Sat, Apr 29, 2017 at 3:04 PM, Al Viro  wrote:
>> > New AT_... flag - AT_NO_JUMPS
>> >
>> > Semantics: pathname resolution must not involve
>> > * traversals of absolute symlinks
>> > * traversals of procfs-style symlinks
>> > * traversals of mountpoints (including bindings, referrals, etc.)
>> > * traversal of .. in the starting point of pathname resolution.
>>
>> Can you clarify this last one?  I assume that ".." will be rejected,
>> but what about "a/../.."?  How about "b" if b is a symlink to ".."?
>> How about "a/b" if a is a directory and b is a symlink to "../.."?
>
> All of those will be rejected - in each of those cases pathname traversal
> leads back into the starting point with .. being the next component to
> handle.

Sounds good.

Might it make sense to split it into two flags, one to prevent moving
between mounts and one for everything else?  I can imagine webservers
and such that are fine with traversing mount points but don't want to
escape their home directory.

--Andy

Re: new ...at() flag: AT_NO_JUMPS

[Andy Lutomirski]

On Sat, Apr 29, 2017 at 4:25 PM, Al Viro  wrote:
> On Sat, Apr 29, 2017 at 04:17:18PM -0700, Andy Lutomirski wrote:
>> On Sat, Apr 29, 2017 at 3:04 PM, Al Viro  wrote:
>> > New AT_... flag - AT_NO_JUMPS
>> >
>> > Semantics: pathname resolution must not involve
>> > * traversals of absolute symlinks
>> > * traversals of procfs-style symlinks
>> > * traversals of mountpoints (including bindings, referrals, etc.)
>> > * traversal of .. in the starting point of pathname resolution.
>>
>> Can you clarify this last one?  I assume that ".." will be rejected,
>> but what about "a/../.."?  How about "b" if b is a symlink to ".."?
>> How about "a/b" if a is a directory and b is a symlink to "../.."?
>
> All of those will be rejected - in each of those cases pathname traversal
> leads back into the starting point with .. being the next component to
> handle.

Sounds good.

Might it make sense to split it into two flags, one to prevent moving
between mounts and one for everything else?  I can imagine webservers
and such that are fine with traversing mount points but don't want to
escape their home directory.

--Andy

RE:drivers:soc:fsl:qbman:qman.c: unsigned long jiffies value

[Karim Eshapa]

On Sat, 29 Apr 2017 18:32:55 -0500, Scott Wood wrote:
>On Sat, 2017-04-29 at 22:43 +0200, Karim Eshapa wrote:
>
>> unsigned long jiffies value sorry for that.
>>
> You mean unsigned long msecs?
>

Yes, I mean usecs. 

>>
>> Signed-off-by: Karim Eshapa 
>> ---
>>  drivers/soc/fsl/qbman/qman.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/soc/fsl/qbman/qman.c b/drivers/soc/fsl/qbman/qman.c
>> index e0df4d1..6e1a44a 100644
>> --- a/drivers/soc/fsl/qbman/qman.c
>> +++ b/drivers/soc/fsl/qbman/qman.c
>> @@ -1084,7 +1084,7 @@ static int drain_mr_fqrni(struct qm_portal *p)
>>* entries well before the ring has been fully consumed, so
>>* we're being *really* paranoid here.
>>*/
>> - unsigned int udel_time = jiffies_to_usecs(1);
>> + unsigned long udel_time = jiffies_to_usecs(1);
>>  
>>   usleep_range(udel_time/2, udel_time);
>>   msg = qm_mr_current(p);

>If unsigned int isn't big enough, then unsigned long won't be either on 32-
>bit.  With such a long delay why not use msleep()?
>

I agree with you in long int.
After looking at Documentation/timers/timers-howto.txt I think
the msleep() is better as we actually have long delay.
may be we can use jiffies_to_msecs() with msleep() in case of we still have 
this large jiffies difference.

>As for the previous patch[1], you're halving the minimum timeout which may not
>be correct.
>
>

For the minimum timeout, I've read the following comments.

 /*
  * if MR was full and h/w had other FQRNI entries to produce, 
we
  * need to allow it time to produce those entries once the
  * existing entries are consumed. A worst-case situation
  * (fully-loaded system) means h/w sequencers may have to do 
3-4
  * other things before servicing the portal's MR pump, each of
  * which (if slow) may take ~50 qman cycles (which is ~200
  * processor cycles). So rounding up and then multiplying this
  * worst-case estimate by a factor of 10, just to be
  * ultra-paranoid, goes as high as 10,000 cycles. NB, we 
consume
  * one entry at a time, so h/w has an opportunity to produce 
new
  * entries well before the ring has been fully consumed, so
  * we're being *really* paranoid here.
  */
  u64 now, then = jiffies;

do {
now = jiffies;
 } while ((then + 1) > now);  

He needs to guarantee certain action so, he made a very large factor of saftey
therefore I've used sleep in range with approximate delay. But we still need 
the driver owner to define appropriate value to put.

>[1] When fixing a patch you've already posted that hasn't yet been applied,
>send a replacement (v2) patch rather than a separate fix.
>

Thanks so much, I'm just newbies :)


Karim   

RE:drivers:soc:fsl:qbman:qman.c: unsigned long jiffies value

[Karim Eshapa]

On Sat, 29 Apr 2017 18:32:55 -0500, Scott Wood wrote:
>On Sat, 2017-04-29 at 22:43 +0200, Karim Eshapa wrote:
>
>> unsigned long jiffies value sorry for that.
>>
> You mean unsigned long msecs?
>

Yes, I mean usecs. 

>>
>> Signed-off-by: Karim Eshapa 
>> ---
>>  drivers/soc/fsl/qbman/qman.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/soc/fsl/qbman/qman.c b/drivers/soc/fsl/qbman/qman.c
>> index e0df4d1..6e1a44a 100644
>> --- a/drivers/soc/fsl/qbman/qman.c
>> +++ b/drivers/soc/fsl/qbman/qman.c
>> @@ -1084,7 +1084,7 @@ static int drain_mr_fqrni(struct qm_portal *p)
>>* entries well before the ring has been fully consumed, so
>>* we're being *really* paranoid here.
>>*/
>> - unsigned int udel_time = jiffies_to_usecs(1);
>> + unsigned long udel_time = jiffies_to_usecs(1);
>>  
>>   usleep_range(udel_time/2, udel_time);
>>   msg = qm_mr_current(p);

>If unsigned int isn't big enough, then unsigned long won't be either on 32-
>bit.  With such a long delay why not use msleep()?
>

I agree with you in long int.
After looking at Documentation/timers/timers-howto.txt I think
the msleep() is better as we actually have long delay.
may be we can use jiffies_to_msecs() with msleep() in case of we still have 
this large jiffies difference.

>As for the previous patch[1], you're halving the minimum timeout which may not
>be correct.
>
>

For the minimum timeout, I've read the following comments.

 /*
  * if MR was full and h/w had other FQRNI entries to produce, 
we
  * need to allow it time to produce those entries once the
  * existing entries are consumed. A worst-case situation
  * (fully-loaded system) means h/w sequencers may have to do 
3-4
  * other things before servicing the portal's MR pump, each of
  * which (if slow) may take ~50 qman cycles (which is ~200
  * processor cycles). So rounding up and then multiplying this
  * worst-case estimate by a factor of 10, just to be
  * ultra-paranoid, goes as high as 10,000 cycles. NB, we 
consume
  * one entry at a time, so h/w has an opportunity to produce 
new
  * entries well before the ring has been fully consumed, so
  * we're being *really* paranoid here.
  */
  u64 now, then = jiffies;

do {
now = jiffies;
 } while ((then + 1) > now);  

He needs to guarantee certain action so, he made a very large factor of saftey
therefore I've used sleep in range with approximate delay. But we still need 
the driver owner to define appropriate value to put.

>[1] When fixing a patch you've already posted that hasn't yet been applied,
>send a replacement (v2) patch rather than a separate fix.
>

Thanks so much, I'm just newbies :)


Karim   

Re: ipsec doesn't route TCP with 4.11 kernel

[Don Bowman]

On 28 April 2017 at 03:13, Steffen Klassert
 wrote:
> On Thu, Apr 27, 2017 at 06:13:38PM -0400, Don Bowman wrote:
>> On 27 April 2017 at 04:42, Steffen Klassert 
>> wrote:
>> > On Wed, Apr 26, 2017 at 10:01:34PM -0700, Cong Wang wrote:
>> >> (Cc'ing netdev and IPSec maintainers)
>> >>
>> >> On Tue, Apr 25, 2017 at 6:08 PM, Don Bowman  wrote:
>>



confirmed, with this patch in place that the tcp functions properly.

Re: ipsec doesn't route TCP with 4.11 kernel

[Don Bowman]

On 28 April 2017 at 03:13, Steffen Klassert
 wrote:
> On Thu, Apr 27, 2017 at 06:13:38PM -0400, Don Bowman wrote:
>> On 27 April 2017 at 04:42, Steffen Klassert 
>> wrote:
>> > On Wed, Apr 26, 2017 at 10:01:34PM -0700, Cong Wang wrote:
>> >> (Cc'ing netdev and IPSec maintainers)
>> >>
>> >> On Tue, Apr 25, 2017 at 6:08 PM, Don Bowman  wrote:
>>



confirmed, with this patch in place that the tcp functions properly.

Re: [PATCH v3 1/4] of: remove *phandle properties from expanded device tree

[kbuild test robot]

Hi Frank,

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.11-rc8 next-20170428]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/frowand-list-gmail-com/of-remove-phandle-properties-from-expanded-device-tree/20170426-000149
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: s390-allmodconfig (attached as .config)
compiler: s390x-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=s390 

All errors (new ones prefixed by >>):

   In file included from include/linux/kobject.h:21:0,
from include/linux/device.h:17,
from include/linux/node.h:17,
from include/linux/cpu.h:16,
from drivers/of/base.c:25:
   drivers/of/base.c: In function '__of_add_phandle_sysfs':
>> drivers/of/base.c:198:23: error: 'pp' undeclared (first use in this function)
 sysfs_bin_attr_init(>attr);
  ^
   include/linux/sysfs.h:54:3: note: in definition of macro 'sysfs_attr_init'
 (attr)->key = &__key;\
  ^~~~
   drivers/of/base.c:198:2: note: in expansion of macro 'sysfs_bin_attr_init'
 sysfs_bin_attr_init(>attr);
 ^~~
   drivers/of/base.c:198:23: note: each undeclared identifier is reported only 
once for each function it appears in
 sysfs_bin_attr_init(>attr);
  ^
   include/linux/sysfs.h:54:3: note: in definition of macro 'sysfs_attr_init'
 (attr)->key = &__key;\
  ^~~~
   drivers/of/base.c:198:2: note: in expansion of macro 'sysfs_bin_attr_init'
 sysfs_bin_attr_init(>attr);
 ^~~

vim +/pp +198 drivers/of/base.c

19   */
20  
21  #define pr_fmt(fmt) "OF: " fmt
22  
23  #include 
24  #include 
  > 25  #include 
26  #include 
27  #include 
28  #include 
29  #include 
30  #include 
31  #include 
32  #include 
33  #include 
34  
35  #include "of_private.h"
36  
37  LIST_HEAD(aliases_lookup);
38  
39  struct device_node *of_root;
40  EXPORT_SYMBOL(of_root);
41  struct device_node *of_chosen;
42  struct device_node *of_aliases;
43  struct device_node *of_stdout;
44  static const char *of_stdout_options;
45  
46  struct kset *of_kset;
47  
48  /*
49   * Used to protect the of_aliases, to hold off addition of nodes to 
sysfs.
50   * This mutex must be held whenever modifications are being made to the
51   * device tree. The of_{attach,detach}_node() and
52   * of_{add,remove,update}_property() helpers make sure this happens.
53   */
54  DEFINE_MUTEX(of_mutex);
55  
56  /* use when traversing tree through the child, sibling,
57   * or parent members of struct device_node.
58   */
59  DEFINE_RAW_SPINLOCK(devtree_lock);
60  
61  int of_n_addr_cells(struct device_node *np)
62  {
63  const __be32 *ip;
64  
65  do {
66  if (np->parent)
67  np = np->parent;
68  ip = of_get_property(np, "#address-cells", NULL);
69  if (ip)
70  return be32_to_cpup(ip);
71  } while (np->parent);
72  /* No #address-cells property for the root node */
73  return OF_ROOT_NODE_ADDR_CELLS_DEFAULT;
74  }
75  EXPORT_SYMBOL(of_n_addr_cells);
76  
77  int of_n_size_cells(struct device_node *np)
78  {
79  const __be32 *ip;
80  
81  do {
82  if (np->parent)
83  np = np->parent;
84  ip = of_get_property(np, "#size-cells", NULL);
85  if (ip)
86  return be32_to_cpup(ip);
87  } while (np->parent);
88  /* No #size-cells property for the root node */
89  return OF_ROOT_NODE_SIZE_CELLS_DEFAULT;
90  }
91  EXPORT_SYMBOL(of_n_size_cells);
92  
93  #ifdef CONFIG_NUMA
94  int __weak of_node_to_nid(struct device_node *np)
95  {
96  return NUMA_NO_NODE;
97  }
98  #endif
99  
   100  #ifndef CONFIG_OF_DYNAMIC
   101  static void of_node_release(struct kobject *kobj)
   102  {
   103  /* Without CONFIG_OF_DYNAMIC, no nodes gets freed */
   104  }
   105  #endif /* CONFIG_OF_DYNAMIC */
   106  
   107  struct kobj_type of_node_ktype = {
   108  .release = of_node_release,
   109  };
   110  
   111  static ssize_t of_node_property_read(struct file *filp, struct kobject 
*kobj,
   112   

Re: [PATCH v3 1/4] of: remove *phandle properties from expanded device tree

[kbuild test robot]

Hi Frank,

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.11-rc8 next-20170428]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/frowand-list-gmail-com/of-remove-phandle-properties-from-expanded-device-tree/20170426-000149
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: s390-allmodconfig (attached as .config)
compiler: s390x-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=s390 

All errors (new ones prefixed by >>):

   In file included from include/linux/kobject.h:21:0,
from include/linux/device.h:17,
from include/linux/node.h:17,
from include/linux/cpu.h:16,
from drivers/of/base.c:25:
   drivers/of/base.c: In function '__of_add_phandle_sysfs':
>> drivers/of/base.c:198:23: error: 'pp' undeclared (first use in this function)
 sysfs_bin_attr_init(>attr);
  ^
   include/linux/sysfs.h:54:3: note: in definition of macro 'sysfs_attr_init'
 (attr)->key = &__key;\
  ^~~~
   drivers/of/base.c:198:2: note: in expansion of macro 'sysfs_bin_attr_init'
 sysfs_bin_attr_init(>attr);
 ^~~
   drivers/of/base.c:198:23: note: each undeclared identifier is reported only 
once for each function it appears in
 sysfs_bin_attr_init(>attr);
  ^
   include/linux/sysfs.h:54:3: note: in definition of macro 'sysfs_attr_init'
 (attr)->key = &__key;\
  ^~~~
   drivers/of/base.c:198:2: note: in expansion of macro 'sysfs_bin_attr_init'
 sysfs_bin_attr_init(>attr);
 ^~~

vim +/pp +198 drivers/of/base.c

19   */
20  
21  #define pr_fmt(fmt) "OF: " fmt
22  
23  #include 
24  #include 
  > 25  #include 
26  #include 
27  #include 
28  #include 
29  #include 
30  #include 
31  #include 
32  #include 
33  #include 
34  
35  #include "of_private.h"
36  
37  LIST_HEAD(aliases_lookup);
38  
39  struct device_node *of_root;
40  EXPORT_SYMBOL(of_root);
41  struct device_node *of_chosen;
42  struct device_node *of_aliases;
43  struct device_node *of_stdout;
44  static const char *of_stdout_options;
45  
46  struct kset *of_kset;
47  
48  /*
49   * Used to protect the of_aliases, to hold off addition of nodes to 
sysfs.
50   * This mutex must be held whenever modifications are being made to the
51   * device tree. The of_{attach,detach}_node() and
52   * of_{add,remove,update}_property() helpers make sure this happens.
53   */
54  DEFINE_MUTEX(of_mutex);
55  
56  /* use when traversing tree through the child, sibling,
57   * or parent members of struct device_node.
58   */
59  DEFINE_RAW_SPINLOCK(devtree_lock);
60  
61  int of_n_addr_cells(struct device_node *np)
62  {
63  const __be32 *ip;
64  
65  do {
66  if (np->parent)
67  np = np->parent;
68  ip = of_get_property(np, "#address-cells", NULL);
69  if (ip)
70  return be32_to_cpup(ip);
71  } while (np->parent);
72  /* No #address-cells property for the root node */
73  return OF_ROOT_NODE_ADDR_CELLS_DEFAULT;
74  }
75  EXPORT_SYMBOL(of_n_addr_cells);
76  
77  int of_n_size_cells(struct device_node *np)
78  {
79  const __be32 *ip;
80  
81  do {
82  if (np->parent)
83  np = np->parent;
84  ip = of_get_property(np, "#size-cells", NULL);
85  if (ip)
86  return be32_to_cpup(ip);
87  } while (np->parent);
88  /* No #size-cells property for the root node */
89  return OF_ROOT_NODE_SIZE_CELLS_DEFAULT;
90  }
91  EXPORT_SYMBOL(of_n_size_cells);
92  
93  #ifdef CONFIG_NUMA
94  int __weak of_node_to_nid(struct device_node *np)
95  {
96  return NUMA_NO_NODE;
97  }
98  #endif
99  
   100  #ifndef CONFIG_OF_DYNAMIC
   101  static void of_node_release(struct kobject *kobj)
   102  {
   103  /* Without CONFIG_OF_DYNAMIC, no nodes gets freed */
   104  }
   105  #endif /* CONFIG_OF_DYNAMIC */
   106  
   107  struct kobj_type of_node_ktype = {
   108  .release = of_node_release,
   109  };
   110  
   111  static ssize_t of_node_property_read(struct file *filp, struct kobject 
*kobj,
   112   

Re: sun50i-a64-pinctrl WARN_ON drivers/base/dd.c:349

[André Przywara]

On 29/04/17 22:28, Adam Borowski wrote:
> On Fri, Apr 28, 2017 at 06:03:14PM -0400, Tejun Heo wrote:
>> On Tue, Apr 18, 2017 at 10:12:16AM +0100, Andre Przywara wrote:
>>> Yeah, so I stack-dumped on the zero allocations and indeed they are
>>> called from cleanup functions:
>>> drivers/pinctrl/pinmux.c:pinmux_generic_free_functions():
>>> devm_kzalloc(sizeof(*indices) * pctldev->num_functions, ...)
>>> (and another one I don't know from the top of the my head, logs at home)
>>>
>>> So my hunch was that once EPROBE_DEFER triggers the devres cleanup, it
>>> uses some reverse list traversal to release all allocated resources
>>> (backwards!), so missing those which get (appended) during the process.
>>> But I don't think that would not work with the locking.
>>> So I have to dig deeper tonight in my logs.
>>
>> If this is a valid use case, we can change devm to repeat till empty
>> but it's a weird thing to do to allocate from a release function.
>>
>> So, something like this.  Only compile tested.

I was wondering if using devm_*alloc in a _release_ function is valid at
all, given that it is called as part of the DEFER clean-up routine.
Looking at pinmux_generic_free_functions() it looks like we could
replace it with a (non-devm_) kmalloc version and it would still work
(given we add a kfree at the end).
Either that or we bail out early if pctldev->num_functions is zero.

> I've tested this, and the results are mixed.  It _does_ make the WARN go
> away, but on the other hand, much later during the boot, another driver
> (sun8i-emac) gets deferred and never undefers.
> 
> Without the patch, there's:
> [ ok ] Synthesizing the initial hotplug events...done.
> [6.666984] bus: 'platform': driver_probe_device: matched device 
> 1c3.ethernet with driver sun8i-emac
> [6.676520] bus: 'platform': really_probe: probing driver sun8i-emac with 
> device 1c3.ethernet
> [6.686479] driver: 'sun8i-emac': driver_bound: bound to device 
> '1c3.ethernet'
> [] [6.694132] bus: 'platform': really_probe: bound device 
> 1c3.ethernet to driver sun8i-emac
> [ ok ng for /dev to be fully populated...done.
> 
> [] Configuring network interfaces...[   11.414884] libphy: 
> 1c3.ethernet: probed
> [   11.449742] bus: 'mdio_bus': driver_probe_device: matched device 
> 1c3.ethernet-0:00 with driver RTL8211E Gigabit Ethernet
> [   11.461013] bus: 'mdio_bus': really_probe: probing driver RTL8211E Gigabit 
> Ethernet with device 1c3.ethernet-0:00
> [   11.471666] driver: 'RTL8211E Gigabit Ethernet': driver_bound: bound to 
> device '1c3.ethernet-0:00'
> [   11.481007] bus: 'mdio_bus': really_probe: bound device 
> 1c3.ethernet-0:00 to driver RTL8211E Gigabit Ethernet
> [   11.491527] RTL8211E Gigabit Ethernet 1c3.ethernet-0:00: attached PHY 
> driver [RTL8211E Gigabit Ethernet] (mii_bus:phy_addr=1c3.ethernet-0:00, 
> irq=-1)
> [   11.505608] sun8i-emac 1c3.ethernet: device MAC address slot 0 
> 02:ba:8f:9e:44:8f
> 
> With the patch:
> [ ok ] Synthesizing the initial hotplug events...done.
> [] Waiting for /dev to be fully populated...[6.325314] bus: 
> 'platform': driver_probe_device: matched device 1c3.ethernet with driver 
> sun8i-emac
> [6.334842] bus: 'platform': really_probe: probing driver sun8i-emac with 
> device 1c3.ethernet
> [6.344253] platform 1c3.ethernet: Driver sun8i-emac requests probe 
> deferral
> [6.351662] platform 1c3.ethernet: Added to deferred list
> done.
> 
> [] Configuring network interfaces...Cannot find device "eth0"
> ifup: failed to bring up eth0
> failed.
> 
> 
> There's a concern, though, that this second driver is not in mainline (and
> won't ever be -- it's being replaced by dwmac-sun8i, but the latter is not
> yet up to scratch), thus I'm not sure how relevant this is.
> 
> The second concern is that I'm using the same tree
> (icenowy/sunxi64-4.11-rc7) and config (plus filesystems) as Icenowy, on the
> same hardware, yet I did see this warning in versions much earlier than her,
> and it doesn't go away in -next for me either.  All that differs are
> toolchain versions (I'm on Debian unstable) and perhaps some u-boot bits.

My understanding is that the probing order is determined during link
time of the kernel - at least for functions using the same initcall
level. For drivers in the same subsystem this is mostly set by the order
in the Makefile, but for drivers from different subsystems their order
might by slightly different depending on parallel compilation. So on
some builds the pinctrl driver gets called late and everything is fine,
whereas on other build it gets called early and returns with -EDEFER,
leading to the issue.

> Because of the amount of churn in sunxi land and the driver's mainlining
> status, I think it'd be good to wait after the merge window that starts
> tomorrow, and re-test then.

Well, I see this issue with pure mainline and defconfig, so no sunxi
specialities here.

Re: sun50i-a64-pinctrl WARN_ON drivers/base/dd.c:349

[André Przywara]

On 29/04/17 22:28, Adam Borowski wrote:
> On Fri, Apr 28, 2017 at 06:03:14PM -0400, Tejun Heo wrote:
>> On Tue, Apr 18, 2017 at 10:12:16AM +0100, Andre Przywara wrote:
>>> Yeah, so I stack-dumped on the zero allocations and indeed they are
>>> called from cleanup functions:
>>> drivers/pinctrl/pinmux.c:pinmux_generic_free_functions():
>>> devm_kzalloc(sizeof(*indices) * pctldev->num_functions, ...)
>>> (and another one I don't know from the top of the my head, logs at home)
>>>
>>> So my hunch was that once EPROBE_DEFER triggers the devres cleanup, it
>>> uses some reverse list traversal to release all allocated resources
>>> (backwards!), so missing those which get (appended) during the process.
>>> But I don't think that would not work with the locking.
>>> So I have to dig deeper tonight in my logs.
>>
>> If this is a valid use case, we can change devm to repeat till empty
>> but it's a weird thing to do to allocate from a release function.
>>
>> So, something like this.  Only compile tested.

I was wondering if using devm_*alloc in a _release_ function is valid at
all, given that it is called as part of the DEFER clean-up routine.
Looking at pinmux_generic_free_functions() it looks like we could
replace it with a (non-devm_) kmalloc version and it would still work
(given we add a kfree at the end).
Either that or we bail out early if pctldev->num_functions is zero.

> I've tested this, and the results are mixed.  It _does_ make the WARN go
> away, but on the other hand, much later during the boot, another driver
> (sun8i-emac) gets deferred and never undefers.
> 
> Without the patch, there's:
> [ ok ] Synthesizing the initial hotplug events...done.
> [6.666984] bus: 'platform': driver_probe_device: matched device 
> 1c3.ethernet with driver sun8i-emac
> [6.676520] bus: 'platform': really_probe: probing driver sun8i-emac with 
> device 1c3.ethernet
> [6.686479] driver: 'sun8i-emac': driver_bound: bound to device 
> '1c3.ethernet'
> [] [6.694132] bus: 'platform': really_probe: bound device 
> 1c3.ethernet to driver sun8i-emac
> [ ok ng for /dev to be fully populated...done.
> 
> [] Configuring network interfaces...[   11.414884] libphy: 
> 1c3.ethernet: probed
> [   11.449742] bus: 'mdio_bus': driver_probe_device: matched device 
> 1c3.ethernet-0:00 with driver RTL8211E Gigabit Ethernet
> [   11.461013] bus: 'mdio_bus': really_probe: probing driver RTL8211E Gigabit 
> Ethernet with device 1c3.ethernet-0:00
> [   11.471666] driver: 'RTL8211E Gigabit Ethernet': driver_bound: bound to 
> device '1c3.ethernet-0:00'
> [   11.481007] bus: 'mdio_bus': really_probe: bound device 
> 1c3.ethernet-0:00 to driver RTL8211E Gigabit Ethernet
> [   11.491527] RTL8211E Gigabit Ethernet 1c3.ethernet-0:00: attached PHY 
> driver [RTL8211E Gigabit Ethernet] (mii_bus:phy_addr=1c3.ethernet-0:00, 
> irq=-1)
> [   11.505608] sun8i-emac 1c3.ethernet: device MAC address slot 0 
> 02:ba:8f:9e:44:8f
> 
> With the patch:
> [ ok ] Synthesizing the initial hotplug events...done.
> [] Waiting for /dev to be fully populated...[6.325314] bus: 
> 'platform': driver_probe_device: matched device 1c3.ethernet with driver 
> sun8i-emac
> [6.334842] bus: 'platform': really_probe: probing driver sun8i-emac with 
> device 1c3.ethernet
> [6.344253] platform 1c3.ethernet: Driver sun8i-emac requests probe 
> deferral
> [6.351662] platform 1c3.ethernet: Added to deferred list
> done.
> 
> [] Configuring network interfaces...Cannot find device "eth0"
> ifup: failed to bring up eth0
> failed.
> 
> 
> There's a concern, though, that this second driver is not in mainline (and
> won't ever be -- it's being replaced by dwmac-sun8i, but the latter is not
> yet up to scratch), thus I'm not sure how relevant this is.
> 
> The second concern is that I'm using the same tree
> (icenowy/sunxi64-4.11-rc7) and config (plus filesystems) as Icenowy, on the
> same hardware, yet I did see this warning in versions much earlier than her,
> and it doesn't go away in -next for me either.  All that differs are
> toolchain versions (I'm on Debian unstable) and perhaps some u-boot bits.

My understanding is that the probing order is determined during link
time of the kernel - at least for functions using the same initcall
level. For drivers in the same subsystem this is mostly set by the order
in the Makefile, but for drivers from different subsystems their order
might by slightly different depending on parallel compilation. So on
some builds the pinctrl driver gets called late and everything is fine,
whereas on other build it gets called early and returns with -EDEFER,
leading to the issue.

> Because of the amount of churn in sunxi land and the driver's mainlining
> status, I think it'd be good to wait after the merge window that starts
> tomorrow, and re-test then.

Well, I see this issue with pure mainline and defconfig, so no sunxi
specialities here.

Re: [PATCH] drivers:soc:fsl:qbman:qman.c: unsigned long jiffies value.

[Scott Wood]

On Sat, 2017-04-29 at 22:43 +0200, Karim Eshapa wrote:
> unsigned long jiffies value sorry for that.

You mean unsigned long msecs?

> 
> Signed-off-by: Karim Eshapa 
> ---
>  drivers/soc/fsl/qbman/qman.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/fsl/qbman/qman.c b/drivers/soc/fsl/qbman/qman.c
> index e0df4d1..6e1a44a 100644
> --- a/drivers/soc/fsl/qbman/qman.c
> +++ b/drivers/soc/fsl/qbman/qman.c
> @@ -1084,7 +1084,7 @@ static int drain_mr_fqrni(struct qm_portal *p)
>    * entries well before the ring has been fully consumed, so
>    * we're being *really* paranoid here.
>    */
> - unsigned int udel_time = jiffies_to_usecs(1);
> + unsigned long udel_time = jiffies_to_usecs(1);
>  
>   usleep_range(udel_time/2, udel_time);
>   msg = qm_mr_current(p);

If unsigned int isn't big enough, then unsigned long won't be either on 32-
bit.  With such a long delay why not use msleep()?

As for the previous patch[1], you're halving the minimum timeout which may not
be correct.

For the NXP people: Is there *really* no better way to handle this than
waiting for so long?  Nothing that can be checked to exit the loop early (at
least, you could exit early if there is more work to do so only the final
iteration takes the full timeout)?  And why is the desired timeout specified
in jiffies, the duration of which can change based on kernel config and
doesn't reflect anything about the hardware?

-Scott

[1] When fixing a patch you've already posted that hasn't yet been applied,
send a replacement (v2) patch rather than a separate fix.

Re: [PATCH] drivers:soc:fsl:qbman:qman.c: unsigned long jiffies value.

[Scott Wood]

On Sat, 2017-04-29 at 22:43 +0200, Karim Eshapa wrote:
> unsigned long jiffies value sorry for that.

You mean unsigned long msecs?

> 
> Signed-off-by: Karim Eshapa 
> ---
>  drivers/soc/fsl/qbman/qman.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/fsl/qbman/qman.c b/drivers/soc/fsl/qbman/qman.c
> index e0df4d1..6e1a44a 100644
> --- a/drivers/soc/fsl/qbman/qman.c
> +++ b/drivers/soc/fsl/qbman/qman.c
> @@ -1084,7 +1084,7 @@ static int drain_mr_fqrni(struct qm_portal *p)
>    * entries well before the ring has been fully consumed, so
>    * we're being *really* paranoid here.
>    */
> - unsigned int udel_time = jiffies_to_usecs(1);
> + unsigned long udel_time = jiffies_to_usecs(1);
>  
>   usleep_range(udel_time/2, udel_time);
>   msg = qm_mr_current(p);

If unsigned int isn't big enough, then unsigned long won't be either on 32-
bit.  With such a long delay why not use msleep()?

As for the previous patch[1], you're halving the minimum timeout which may not
be correct.

For the NXP people: Is there *really* no better way to handle this than
waiting for so long?  Nothing that can be checked to exit the loop early (at
least, you could exit early if there is more work to do so only the final
iteration takes the full timeout)?  And why is the desired timeout specified
in jiffies, the duration of which can change based on kernel config and
doesn't reflect anything about the hardware?

-Scott

[1] When fixing a patch you've already posted that hasn't yet been applied,
send a replacement (v2) patch rather than a separate fix.

[rcu:dev.2017.04.28a 41/45] include/linux/notifier.h:77:21: error: field 'srcu' has incomplete type

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
dev.2017.04.28a
head:   1205059ca5d4835e9213ff943ce3a51980718b5d
commit: e01ef0529ed548c1b30206058c2b5eecbbc07998 [41/45] srcu: Make SRCU be 
once again optional
config: sparc64-allnoconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout e01ef0529ed548c1b30206058c2b5eecbbc07998
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

All errors (new ones prefixed by >>):

   In file included from include/linux/memory_hotplug.h:6:0,
from include/linux/mmzone.h:749,
from include/linux/gfp.h:5,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from init/main.c:16:
>> include/linux/notifier.h:77:21: error: field 'srcu' has incomplete type
 struct srcu_struct srcu;
^~~~

vim +/srcu +77 include/linux/notifier.h

e041c6834 Alan Stern2006-03-27  61  struct atomic_notifier_head {
e041c6834 Alan Stern2006-03-27  62  spinlock_t lock;
374a8e0dc Arnd Bergmann 2010-02-24  63  struct notifier_block __rcu 
*head;
e041c6834 Alan Stern2006-03-27  64  };
e041c6834 Alan Stern2006-03-27  65  
e041c6834 Alan Stern2006-03-27  66  struct blocking_notifier_head {
e041c6834 Alan Stern2006-03-27  67  struct rw_semaphore rwsem;
374a8e0dc Arnd Bergmann 2010-02-24  68  struct notifier_block __rcu 
*head;
e041c6834 Alan Stern2006-03-27  69  };
e041c6834 Alan Stern2006-03-27  70  
e041c6834 Alan Stern2006-03-27  71  struct raw_notifier_head {
374a8e0dc Arnd Bergmann 2010-02-24  72  struct notifier_block __rcu 
*head;
e041c6834 Alan Stern2006-03-27  73  };
e041c6834 Alan Stern2006-03-27  74  
eabc06940 Alan Stern2006-10-04  75  struct srcu_notifier_head {
eabc06940 Alan Stern2006-10-04  76  struct mutex mutex;
eabc06940 Alan Stern2006-10-04 @77  struct srcu_struct srcu;
374a8e0dc Arnd Bergmann 2010-02-24  78  struct notifier_block __rcu 
*head;
eabc06940 Alan Stern2006-10-04  79  };
eabc06940 Alan Stern2006-10-04  80  
e041c6834 Alan Stern2006-03-27  81  #define ATOMIC_INIT_NOTIFIER_HEAD(name) 
do {\
e041c6834 Alan Stern2006-03-27  82  
spin_lock_init(&(name)->lock);  \
e041c6834 Alan Stern2006-03-27  83  (name)->head = NULL;
\
e041c6834 Alan Stern2006-03-27  84  } while (0)
e041c6834 Alan Stern2006-03-27  85  #define 
BLOCKING_INIT_NOTIFIER_HEAD(name) do {  \

:: The code at line 77 was first introduced by commit
:: eabc069401bcf45bcc3f19e643017bf761780aa8 [PATCH] Add SRCU-based notifier 
chains

:: TO: Alan Stern 
:: CC: Linus Torvalds 

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


.config.gz
Description: application/gzip

[rcu:dev.2017.04.28a 41/45] include/linux/notifier.h:77:21: error: field 'srcu' has incomplete type

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
dev.2017.04.28a
head:   1205059ca5d4835e9213ff943ce3a51980718b5d
commit: e01ef0529ed548c1b30206058c2b5eecbbc07998 [41/45] srcu: Make SRCU be 
once again optional
config: sparc64-allnoconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout e01ef0529ed548c1b30206058c2b5eecbbc07998
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

All errors (new ones prefixed by >>):

   In file included from include/linux/memory_hotplug.h:6:0,
from include/linux/mmzone.h:749,
from include/linux/gfp.h:5,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from init/main.c:16:
>> include/linux/notifier.h:77:21: error: field 'srcu' has incomplete type
 struct srcu_struct srcu;
^~~~

vim +/srcu +77 include/linux/notifier.h

e041c6834 Alan Stern2006-03-27  61  struct atomic_notifier_head {
e041c6834 Alan Stern2006-03-27  62  spinlock_t lock;
374a8e0dc Arnd Bergmann 2010-02-24  63  struct notifier_block __rcu 
*head;
e041c6834 Alan Stern2006-03-27  64  };
e041c6834 Alan Stern2006-03-27  65  
e041c6834 Alan Stern2006-03-27  66  struct blocking_notifier_head {
e041c6834 Alan Stern2006-03-27  67  struct rw_semaphore rwsem;
374a8e0dc Arnd Bergmann 2010-02-24  68  struct notifier_block __rcu 
*head;
e041c6834 Alan Stern2006-03-27  69  };
e041c6834 Alan Stern2006-03-27  70  
e041c6834 Alan Stern2006-03-27  71  struct raw_notifier_head {
374a8e0dc Arnd Bergmann 2010-02-24  72  struct notifier_block __rcu 
*head;
e041c6834 Alan Stern2006-03-27  73  };
e041c6834 Alan Stern2006-03-27  74  
eabc06940 Alan Stern2006-10-04  75  struct srcu_notifier_head {
eabc06940 Alan Stern2006-10-04  76  struct mutex mutex;
eabc06940 Alan Stern2006-10-04 @77  struct srcu_struct srcu;
374a8e0dc Arnd Bergmann 2010-02-24  78  struct notifier_block __rcu 
*head;
eabc06940 Alan Stern2006-10-04  79  };
eabc06940 Alan Stern2006-10-04  80  
e041c6834 Alan Stern2006-03-27  81  #define ATOMIC_INIT_NOTIFIER_HEAD(name) 
do {\
e041c6834 Alan Stern2006-03-27  82  
spin_lock_init(&(name)->lock);  \
e041c6834 Alan Stern2006-03-27  83  (name)->head = NULL;
\
e041c6834 Alan Stern2006-03-27  84  } while (0)
e041c6834 Alan Stern2006-03-27  85  #define 
BLOCKING_INIT_NOTIFIER_HEAD(name) do {  \

:: The code at line 77 was first introduced by commit
:: eabc069401bcf45bcc3f19e643017bf761780aa8 [PATCH] Add SRCU-based notifier 
chains

:: TO: Alan Stern 
:: CC: Linus Torvalds 

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


.config.gz
Description: application/gzip

Re: [PATCH v1 1/2] PCI: mediatek: Add Mediatek PCIe host controller support

[kbuild test robot]

Hi Ryder,

[auto build test ERROR on pci/next]
[also build test ERROR on v4.11-rc8 next-20170428]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ryder-Lee/Add-PCIe-host-driver-support-for-Mediatek-SoCs/20170429-181028
base:   https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: s390-allmodconfig (attached as .config)
compiler: s390x-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=s390 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `mtk_pcie_probe':
>> drivers/pci/host/.tmp_gl_pcie-mediatek.o:(.text+0x5b68c): undefined 
>> reference to `pci_fixup_irqs'

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


.config.gz
Description: application/gzip

Re: [PATCH v1 1/2] PCI: mediatek: Add Mediatek PCIe host controller support

[kbuild test robot]

Hi Ryder,

[auto build test ERROR on pci/next]
[also build test ERROR on v4.11-rc8 next-20170428]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ryder-Lee/Add-PCIe-host-driver-support-for-Mediatek-SoCs/20170429-181028
base:   https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: s390-allmodconfig (attached as .config)
compiler: s390x-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=s390 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `mtk_pcie_probe':
>> drivers/pci/host/.tmp_gl_pcie-mediatek.o:(.text+0x5b68c): undefined 
>> reference to `pci_fixup_irqs'

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


.config.gz
Description: application/gzip

Re: new ...at() flag: AT_NO_JUMPS

[Al Viro]

On Sat, Apr 29, 2017 at 04:17:18PM -0700, Andy Lutomirski wrote:
> On Sat, Apr 29, 2017 at 3:04 PM, Al Viro  wrote:
> > New AT_... flag - AT_NO_JUMPS
> >
> > Semantics: pathname resolution must not involve
> > * traversals of absolute symlinks
> > * traversals of procfs-style symlinks
> > * traversals of mountpoints (including bindings, referrals, etc.)
> > * traversal of .. in the starting point of pathname resolution.
> 
> Can you clarify this last one?  I assume that ".." will be rejected,
> but what about "a/../.."?  How about "b" if b is a symlink to ".."?
> How about "a/b" if a is a directory and b is a symlink to "../.."?

All of those will be rejected - in each of those cases pathname traversal
leads back into the starting point with .. being the next component to
handle.

Re: new ...at() flag: AT_NO_JUMPS

[Al Viro]

On Sat, Apr 29, 2017 at 04:17:18PM -0700, Andy Lutomirski wrote:
> On Sat, Apr 29, 2017 at 3:04 PM, Al Viro  wrote:
> > New AT_... flag - AT_NO_JUMPS
> >
> > Semantics: pathname resolution must not involve
> > * traversals of absolute symlinks
> > * traversals of procfs-style symlinks
> > * traversals of mountpoints (including bindings, referrals, etc.)
> > * traversal of .. in the starting point of pathname resolution.
> 
> Can you clarify this last one?  I assume that ".." will be rejected,
> but what about "a/../.."?  How about "b" if b is a symlink to ".."?
> How about "a/b" if a is a directory and b is a symlink to "../.."?

All of those will be rejected - in each of those cases pathname traversal
leads back into the starting point with .. being the next component to
handle.

Re: new ...at() flag: AT_NO_JUMPS

[Andy Lutomirski]

On Sat, Apr 29, 2017 at 3:04 PM, Al Viro  wrote:
> New AT_... flag - AT_NO_JUMPS
>
> Semantics: pathname resolution must not involve
> * traversals of absolute symlinks
> * traversals of procfs-style symlinks
> * traversals of mountpoints (including bindings, referrals, etc.)
> * traversal of .. in the starting point of pathname resolution.

Can you clarify this last one?  I assume that ".." will be rejected,
but what about "a/../.."?  How about "b" if b is a symlink to ".."?
How about "a/b" if a is a directory and b is a symlink to "../.."?

> Right now I have it hooked only for fstatat() and friends; it could be
> easily extended to any ...at() syscalls.  Objections?

I like it, assuming the answers to all the questions above are that
they will be rejected.

Re: new ...at() flag: AT_NO_JUMPS

[Andy Lutomirski]

On Sat, Apr 29, 2017 at 3:04 PM, Al Viro  wrote:
> New AT_... flag - AT_NO_JUMPS
>
> Semantics: pathname resolution must not involve
> * traversals of absolute symlinks
> * traversals of procfs-style symlinks
> * traversals of mountpoints (including bindings, referrals, etc.)
> * traversal of .. in the starting point of pathname resolution.

Can you clarify this last one?  I assume that ".." will be rejected,
but what about "a/../.."?  How about "b" if b is a symlink to ".."?
How about "a/b" if a is a directory and b is a symlink to "../.."?

> Right now I have it hooked only for fstatat() and friends; it could be
> easily extended to any ...at() syscalls.  Objections?

I like it, assuming the answers to all the questions above are that
they will be rejected.

Re: [PATCH v8 05/10] media: venus: adding core part and helper functions

[Sakari Ailus]

Hi, Stan!!

On Fri, Apr 28, 2017 at 12:13:52PM +0300, Stanimir Varbanov wrote:
...
> +int helper_get_bufreq(struct venus_inst *inst, u32 type,
> +   struct hfi_buffer_requirements *req)
> +{
> + u32 ptype = HFI_PROPERTY_CONFIG_BUFFER_REQUIREMENTS;
> + union hfi_get_property hprop;
> + int ret, i;

unsigned int i ? It's an array index...

> +
> + if (req)
> + memset(req, 0, sizeof(*req));
> +
> + ret = hfi_session_get_property(inst, ptype, );
> + if (ret)
> + return ret;
> +
> + ret = -EINVAL;
> +
> + for (i = 0; i < HFI_BUFFER_TYPE_MAX; i++) {
> + if (hprop.bufreq[i].type != type)
> + continue;
> +
> + if (req)
> + memcpy(req, [i], sizeof(*req));
> + ret = 0;
> + break;
> + }
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(helper_get_bufreq);

As these are global symbols but still specific to a single driver, it'd be
good to have them prefixed with a common prefix. How about "venus"? You
actually already have that in a macro in the header. :-)

> +
> +int helper_set_input_resolution(struct venus_inst *inst, unsigned int width,
> + unsigned int height)
> +{
> + u32 ptype = HFI_PROPERTY_PARAM_FRAME_SIZE;
> + struct hfi_framesize fs;
> +
> + fs.buffer_type = HFI_BUFFER_INPUT;
> + fs.width = width;
> + fs.height = height;
> +
> + return hfi_session_set_property(inst, ptype, );
> +}
> +EXPORT_SYMBOL_GPL(helper_set_input_resolution);
> +
> +int helper_set_output_resolution(struct venus_inst *inst, unsigned int width,
> +  unsigned int height)
> +{
> + u32 ptype = HFI_PROPERTY_PARAM_FRAME_SIZE;
> + struct hfi_framesize fs;
> +
> + fs.buffer_type = HFI_BUFFER_OUTPUT;
> + fs.width = width;
> + fs.height = height;
> +
> + return hfi_session_set_property(inst, ptype, );
> +}
> +EXPORT_SYMBOL_GPL(helper_set_output_resolution);
> +
> +int helper_set_num_bufs(struct venus_inst *inst, unsigned int input_bufs,
> + unsigned int output_bufs)
> +{
> + u32 ptype = HFI_PROPERTY_PARAM_BUFFER_COUNT_ACTUAL;
> + struct hfi_buffer_count_actual buf_count;
> + int ret;
> +
> + buf_count.type = HFI_BUFFER_INPUT;
> + buf_count.count_actual = input_bufs;
> +
> + ret = hfi_session_set_property(inst, ptype, _count);
> + if (ret)
> + return ret;
> +
> + buf_count.type = HFI_BUFFER_OUTPUT;
> + buf_count.count_actual = output_bufs;
> +
> + return hfi_session_set_property(inst, ptype, _count);
> +}
> +EXPORT_SYMBOL_GPL(helper_set_num_bufs);
> +
> +int helper_set_color_format(struct venus_inst *inst, u32 pixfmt)
> +{
> + struct hfi_uncompressed_format_select fmt;
> + u32 ptype = HFI_PROPERTY_PARAM_UNCOMPRESSED_FORMAT_SELECT;
> + int ret;
> +
> + if (inst->session_type == VIDC_SESSION_TYPE_DEC)
> + fmt.buffer_type = HFI_BUFFER_OUTPUT;
> + else if (inst->session_type == VIDC_SESSION_TYPE_ENC)
> + fmt.buffer_type = HFI_BUFFER_INPUT;
> + else
> + return -EINVAL;
> +
> + switch (pixfmt) {
> + case V4L2_PIX_FMT_NV12:
> + fmt.format = HFI_COLOR_FORMAT_NV12;
> + break;
> + case V4L2_PIX_FMT_NV21:
> + fmt.format = HFI_COLOR_FORMAT_NV21;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + ret = hfi_session_set_property(inst, ptype, );
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(helper_set_color_format);
> +
> +static void delayed_process_buf_func(struct work_struct *work)
> +{
> + struct venus_buffer *buf, *n;
> + struct venus_inst *inst;
> + int ret;
> +
> + inst = container_of(work, struct venus_inst, delayed_process_work);
> +
> + mutex_lock(>lock);
> +
> + if (!(inst->streamon_out & inst->streamon_cap))
> + goto unlock;
> +
> + list_for_each_entry_safe(buf, n, >delayed_process, ref_list) {
> + if (buf->flags & HFI_BUFFERFLAG_READONLY)
> + continue;
> +
> + ret = session_process_buf(inst, >vb);
> + if (ret)
> + return_buf_error(inst, >vb);
> +
> + list_del_init(>ref_list);
> + }
> +unlock:
> + mutex_unlock(>lock);
> +}
> +
> +void helper_release_buf_ref(struct venus_inst *inst, unsigned int idx)
> +{
> + struct venus_buffer *buf;
> +
> + list_for_each_entry(buf, >registeredbufs, reg_list) {
> + if (buf->vb.vb2_buf.index == idx) {
> + buf->flags &= ~HFI_BUFFERFLAG_READONLY;
> + schedule_work(>delayed_process_work);
> + break;
> + }
> + }
> +}
> +EXPORT_SYMBOL_GPL(helper_release_buf_ref);
> +
> +void helper_acquire_buf_ref(struct vb2_v4l2_buffer *vbuf)
> +{
> + struct venus_buffer *buf = 

Re: [PATCH v8 05/10] media: venus: adding core part and helper functions

[Sakari Ailus]

Hi, Stan!!

On Fri, Apr 28, 2017 at 12:13:52PM +0300, Stanimir Varbanov wrote:
...
> +int helper_get_bufreq(struct venus_inst *inst, u32 type,
> +   struct hfi_buffer_requirements *req)
> +{
> + u32 ptype = HFI_PROPERTY_CONFIG_BUFFER_REQUIREMENTS;
> + union hfi_get_property hprop;
> + int ret, i;

unsigned int i ? It's an array index...

> +
> + if (req)
> + memset(req, 0, sizeof(*req));
> +
> + ret = hfi_session_get_property(inst, ptype, );
> + if (ret)
> + return ret;
> +
> + ret = -EINVAL;
> +
> + for (i = 0; i < HFI_BUFFER_TYPE_MAX; i++) {
> + if (hprop.bufreq[i].type != type)
> + continue;
> +
> + if (req)
> + memcpy(req, [i], sizeof(*req));
> + ret = 0;
> + break;
> + }
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(helper_get_bufreq);

As these are global symbols but still specific to a single driver, it'd be
good to have them prefixed with a common prefix. How about "venus"? You
actually already have that in a macro in the header. :-)

> +
> +int helper_set_input_resolution(struct venus_inst *inst, unsigned int width,
> + unsigned int height)
> +{
> + u32 ptype = HFI_PROPERTY_PARAM_FRAME_SIZE;
> + struct hfi_framesize fs;
> +
> + fs.buffer_type = HFI_BUFFER_INPUT;
> + fs.width = width;
> + fs.height = height;
> +
> + return hfi_session_set_property(inst, ptype, );
> +}
> +EXPORT_SYMBOL_GPL(helper_set_input_resolution);
> +
> +int helper_set_output_resolution(struct venus_inst *inst, unsigned int width,
> +  unsigned int height)
> +{
> + u32 ptype = HFI_PROPERTY_PARAM_FRAME_SIZE;
> + struct hfi_framesize fs;
> +
> + fs.buffer_type = HFI_BUFFER_OUTPUT;
> + fs.width = width;
> + fs.height = height;
> +
> + return hfi_session_set_property(inst, ptype, );
> +}
> +EXPORT_SYMBOL_GPL(helper_set_output_resolution);
> +
> +int helper_set_num_bufs(struct venus_inst *inst, unsigned int input_bufs,
> + unsigned int output_bufs)
> +{
> + u32 ptype = HFI_PROPERTY_PARAM_BUFFER_COUNT_ACTUAL;
> + struct hfi_buffer_count_actual buf_count;
> + int ret;
> +
> + buf_count.type = HFI_BUFFER_INPUT;
> + buf_count.count_actual = input_bufs;
> +
> + ret = hfi_session_set_property(inst, ptype, _count);
> + if (ret)
> + return ret;
> +
> + buf_count.type = HFI_BUFFER_OUTPUT;
> + buf_count.count_actual = output_bufs;
> +
> + return hfi_session_set_property(inst, ptype, _count);
> +}
> +EXPORT_SYMBOL_GPL(helper_set_num_bufs);
> +
> +int helper_set_color_format(struct venus_inst *inst, u32 pixfmt)
> +{
> + struct hfi_uncompressed_format_select fmt;
> + u32 ptype = HFI_PROPERTY_PARAM_UNCOMPRESSED_FORMAT_SELECT;
> + int ret;
> +
> + if (inst->session_type == VIDC_SESSION_TYPE_DEC)
> + fmt.buffer_type = HFI_BUFFER_OUTPUT;
> + else if (inst->session_type == VIDC_SESSION_TYPE_ENC)
> + fmt.buffer_type = HFI_BUFFER_INPUT;
> + else
> + return -EINVAL;
> +
> + switch (pixfmt) {
> + case V4L2_PIX_FMT_NV12:
> + fmt.format = HFI_COLOR_FORMAT_NV12;
> + break;
> + case V4L2_PIX_FMT_NV21:
> + fmt.format = HFI_COLOR_FORMAT_NV21;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + ret = hfi_session_set_property(inst, ptype, );
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(helper_set_color_format);
> +
> +static void delayed_process_buf_func(struct work_struct *work)
> +{
> + struct venus_buffer *buf, *n;
> + struct venus_inst *inst;
> + int ret;
> +
> + inst = container_of(work, struct venus_inst, delayed_process_work);
> +
> + mutex_lock(>lock);
> +
> + if (!(inst->streamon_out & inst->streamon_cap))
> + goto unlock;
> +
> + list_for_each_entry_safe(buf, n, >delayed_process, ref_list) {
> + if (buf->flags & HFI_BUFFERFLAG_READONLY)
> + continue;
> +
> + ret = session_process_buf(inst, >vb);
> + if (ret)
> + return_buf_error(inst, >vb);
> +
> + list_del_init(>ref_list);
> + }
> +unlock:
> + mutex_unlock(>lock);
> +}
> +
> +void helper_release_buf_ref(struct venus_inst *inst, unsigned int idx)
> +{
> + struct venus_buffer *buf;
> +
> + list_for_each_entry(buf, >registeredbufs, reg_list) {
> + if (buf->vb.vb2_buf.index == idx) {
> + buf->flags &= ~HFI_BUFFERFLAG_READONLY;
> + schedule_work(>delayed_process_work);
> + break;
> + }
> + }
> +}
> +EXPORT_SYMBOL_GPL(helper_release_buf_ref);
> +
> +void helper_acquire_buf_ref(struct vb2_v4l2_buffer *vbuf)
> +{
> + struct venus_buffer *buf = 

[PATCH] tools/virtio: fix spelling mistake: "wakeus" -> "wakeups"

[Colin King]

From: Colin Ian King 

trivial fix to spelling mistake in an error message.

Signed-off-by: Colin Ian King 
---
 tools/virtio/virtio_test.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/virtio/virtio_test.c b/tools/virtio/virtio_test.c
index 76d6f583c249..0fecaec90d0d 100644
--- a/tools/virtio/virtio_test.c
+++ b/tools/virtio/virtio_test.c
@@ -202,7 +202,7 @@ static void run_test(struct vdev_info *dev, struct vq_info 
*vq,
test = 0;
r = ioctl(dev->control, VHOST_TEST_RUN, );
assert(r >= 0);
-   fprintf(stderr, "spurious wakeus: 0x%llx\n", spurious);
+   fprintf(stderr, "spurious wakeups: 0x%llx\n", spurious);
 }
 
 const char optstring[] = "h";
-- 
2.11.0

[PATCH] tools/virtio: fix spelling mistake: "wakeus" -> "wakeups"

[Colin King]

From: Colin Ian King 

trivial fix to spelling mistake in an error message.

Signed-off-by: Colin Ian King 
---
 tools/virtio/virtio_test.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/virtio/virtio_test.c b/tools/virtio/virtio_test.c
index 76d6f583c249..0fecaec90d0d 100644
--- a/tools/virtio/virtio_test.c
+++ b/tools/virtio/virtio_test.c
@@ -202,7 +202,7 @@ static void run_test(struct vdev_info *dev, struct vq_info 
*vq,
test = 0;
r = ioctl(dev->control, VHOST_TEST_RUN, );
assert(r >= 0);
-   fprintf(stderr, "spurious wakeus: 0x%llx\n", spurious);
+   fprintf(stderr, "spurious wakeups: 0x%llx\n", spurious);
 }
 
 const char optstring[] = "h";
-- 
2.11.0

[PATCH][V2] scsi: megaraid_sas: fix spelling mistakes: "oustanding" -> "outstanding"

[Colin King]

From: Colin Ian King 

trivial fix to spelling mistakes in dev_info and scmd_printk
messages.  Also join lines on split literal string to clean up
checkpatch warning.

Signed-off-by: Colin Ian King 
---
 drivers/scsi/megaraid/megaraid_sas_base.c   | 2 +-
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 316c3df0c3fd..0a9478fdb58b 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -2638,7 +2638,7 @@ static int megasas_wait_for_outstanding(struct 
megasas_instance *instance)
do {
if ((fw_state == MFI_STATE_FAULT) || 
atomic_read(>fw_outstanding)) {
dev_info(>pdev->dev,
-   "%s:%d waiting_for_outstanding: before issue 
OCR. FW state = 0x%x, oustanding 0x%x\n",
+   "%s:%d waiting_for_outstanding: before issue 
OCR. FW state = 0x%x, outstanding 0x%x\n",
__func__, __LINE__, fw_state, 
atomic_read(>fw_outstanding));
if (i == 3)
goto kill_hba_and_failed;
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index f990ab4d45e1..adba9f450dec 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -3975,8 +3975,7 @@ int megasas_task_abort_fusion(struct scsi_cmnd *scmd)
 
if (!smid) {
ret = SUCCESS;
-   scmd_printk(KERN_NOTICE, scmd, "Command for which abort is"
-   " issued is not found in oustanding commands\n");
+   scmd_printk(KERN_NOTICE, scmd, "Command for which abort is 
issued is not found in outstanding commands\n");
mutex_unlock(>reset_mutex);
goto out;
}
-- 
2.11.0

[PATCH][V2] scsi: megaraid_sas: fix spelling mistakes: "oustanding" -> "outstanding"

[Colin King]

From: Colin Ian King 

trivial fix to spelling mistakes in dev_info and scmd_printk
messages.  Also join lines on split literal string to clean up
checkpatch warning.

Signed-off-by: Colin Ian King 
---
 drivers/scsi/megaraid/megaraid_sas_base.c   | 2 +-
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 316c3df0c3fd..0a9478fdb58b 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -2638,7 +2638,7 @@ static int megasas_wait_for_outstanding(struct 
megasas_instance *instance)
do {
if ((fw_state == MFI_STATE_FAULT) || 
atomic_read(>fw_outstanding)) {
dev_info(>pdev->dev,
-   "%s:%d waiting_for_outstanding: before issue 
OCR. FW state = 0x%x, oustanding 0x%x\n",
+   "%s:%d waiting_for_outstanding: before issue 
OCR. FW state = 0x%x, outstanding 0x%x\n",
__func__, __LINE__, fw_state, 
atomic_read(>fw_outstanding));
if (i == 3)
goto kill_hba_and_failed;
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index f990ab4d45e1..adba9f450dec 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -3975,8 +3975,7 @@ int megasas_task_abort_fusion(struct scsi_cmnd *scmd)
 
if (!smid) {
ret = SUCCESS;
-   scmd_printk(KERN_NOTICE, scmd, "Command for which abort is"
-   " issued is not found in oustanding commands\n");
+   scmd_printk(KERN_NOTICE, scmd, "Command for which abort is 
issued is not found in outstanding commands\n");
mutex_unlock(>reset_mutex);
goto out;
}
-- 
2.11.0

new ...at() flag: AT_NO_JUMPS

[Al Viro]

New AT_... flag - AT_NO_JUMPS

Semantics: pathname resolution must not involve
* traversals of absolute symlinks
* traversals of procfs-style symlinks
* traversals of mountpoints (including bindings, referrals, etc.)
* traversal of .. in the starting point of pathname resolution.

All of those lead to failure with -ELOOP.  Relative symlinks are fine,
as long as their resolution does not end up stepping into the conditions
above.

It guarantees that result of successful pathname resolution will be on the
same filesystem as its starting point and within the subtree rooted at
the starting point.

Right now I have it hooked only for fstatat() and friends; it could be
easily extended to any ...at() syscalls.  Objections?

commit 2765f14b0cbb4240a6a3dda353d7014b6de19db9
Author: Al Viro 
Date:   Sat Mar 18 16:27:55 2017 -0400

namei: new flag (LOOKUP_NO_JUMPS)

semantics: fail with -ELOOP upon
* attempt to cross mountpoint (including bindings)
* attempt to traverse a non-relative symlink
* attempt to cross the starting point by ".." traversal

Matching AT_... flag: AT_NO_JUMPS introduced, fstatat(2) (and
corresponding statx/stat64 variants) taught about it.

Signed-off-by: Al Viro 

diff --git a/fs/namei.c b/fs/namei.c
index d41fab78798b..de1f07ec8ccd 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -874,6 +874,8 @@ static int nd_jump_root(struct nameidata *nd)
path_get(>path);
nd->inode = nd->path.dentry->d_inode;
}
+   if (unlikely(nd->flags & LOOKUP_NO_JUMPS))
+   return -ELOOP;
nd->flags |= LOOKUP_JUMPED;
return 0;
 }
@@ -1054,14 +1056,18 @@ const char *get_link(struct nameidata *nd)
} else {
res = get(dentry, inode, >done);
}
+   if (unlikely(nd->flags & LOOKUP_NO_JUMPS) &&
+   unlikely(nd->flags & LOOKUP_JUMPED))
+   return ERR_PTR(-ELOOP);
if (IS_ERR_OR_NULL(res))
return res;
}
if (*res == '/') {
if (!nd->root.mnt)
set_root(nd);
-   if (unlikely(nd_jump_root(nd)))
-   return ERR_PTR(-ECHILD);
+   error = nd_jump_root(nd);
+   if (unlikely(error))
+   return ERR_PTR(error);
while (unlikely(*++res == '/'))
;
}
@@ -1245,12 +1251,16 @@ static int follow_managed(struct path *path, struct 
nameidata *nd)
break;
}
 
-   if (need_mntput && path->mnt == mnt)
-   mntput(path->mnt);
+   if (need_mntput) {
+   if (path->mnt == mnt)
+   mntput(path->mnt);
+   if (unlikely(nd->flags & LOOKUP_NO_JUMPS))
+   ret = -ELOOP;
+   else
+   nd->flags |= LOOKUP_JUMPED;
+   }
if (ret == -EISDIR || !ret)
ret = 1;
-   if (need_mntput)
-   nd->flags |= LOOKUP_JUMPED;
if (unlikely(ret < 0))
path_put_conditional(path, nd);
return ret;
@@ -1307,6 +1317,8 @@ static bool __follow_mount_rcu(struct nameidata *nd, 
struct path *path,
mounted = __lookup_mnt(path->mnt, path->dentry);
if (!mounted)
break;
+   if (unlikely(nd->flags & LOOKUP_NO_JUMPS))
+   return false;
path->mnt = >mnt;
path->dentry = mounted->mnt.mnt_root;
nd->flags |= LOOKUP_JUMPED;
@@ -1327,8 +1339,11 @@ static int follow_dotdot_rcu(struct nameidata *nd)
struct inode *inode = nd->inode;
 
while (1) {
-   if (path_equal(>path, >root))
+   if (unlikely(path_equal(>path, >root))) {
+   if (nd->flags & LOOKUP_NO_JUMPS)
+   return -ELOOP;
break;
+   }
if (nd->path.dentry != nd->path.mnt->mnt_root) {
struct dentry *old = nd->path.dentry;
struct dentry *parent = old->d_parent;
@@ -1455,8 +1470,9 @@ static int path_parent_directory(struct path *path)
 static int follow_dotdot(struct nameidata *nd)
 {
while(1) {
-   if (nd->path.dentry == nd->root.dentry &&
-   nd->path.mnt == nd->root.mnt) {
+   if (unlikely(path_equal(>path, >root))) {
+   if (nd->flags & LOOKUP_NO_JUMPS)
+   return -ELOOP;
break;
}
if (nd->path.dentry != nd->path.mnt->mnt_root) {
@@ -2177,14 +2193,16 @@ static const char *path_init(struct nameidata *nd, 
unsigned flags)
 
nd->m_seq = 

new ...at() flag: AT_NO_JUMPS

[Al Viro]

New AT_... flag - AT_NO_JUMPS

Semantics: pathname resolution must not involve
* traversals of absolute symlinks
* traversals of procfs-style symlinks
* traversals of mountpoints (including bindings, referrals, etc.)
* traversal of .. in the starting point of pathname resolution.

All of those lead to failure with -ELOOP.  Relative symlinks are fine,
as long as their resolution does not end up stepping into the conditions
above.

It guarantees that result of successful pathname resolution will be on the
same filesystem as its starting point and within the subtree rooted at
the starting point.

Right now I have it hooked only for fstatat() and friends; it could be
easily extended to any ...at() syscalls.  Objections?

commit 2765f14b0cbb4240a6a3dda353d7014b6de19db9
Author: Al Viro 
Date:   Sat Mar 18 16:27:55 2017 -0400

namei: new flag (LOOKUP_NO_JUMPS)

semantics: fail with -ELOOP upon
* attempt to cross mountpoint (including bindings)
* attempt to traverse a non-relative symlink
* attempt to cross the starting point by ".." traversal

Matching AT_... flag: AT_NO_JUMPS introduced, fstatat(2) (and
corresponding statx/stat64 variants) taught about it.

Signed-off-by: Al Viro 

diff --git a/fs/namei.c b/fs/namei.c
index d41fab78798b..de1f07ec8ccd 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -874,6 +874,8 @@ static int nd_jump_root(struct nameidata *nd)
path_get(>path);
nd->inode = nd->path.dentry->d_inode;
}
+   if (unlikely(nd->flags & LOOKUP_NO_JUMPS))
+   return -ELOOP;
nd->flags |= LOOKUP_JUMPED;
return 0;
 }
@@ -1054,14 +1056,18 @@ const char *get_link(struct nameidata *nd)
} else {
res = get(dentry, inode, >done);
}
+   if (unlikely(nd->flags & LOOKUP_NO_JUMPS) &&
+   unlikely(nd->flags & LOOKUP_JUMPED))
+   return ERR_PTR(-ELOOP);
if (IS_ERR_OR_NULL(res))
return res;
}
if (*res == '/') {
if (!nd->root.mnt)
set_root(nd);
-   if (unlikely(nd_jump_root(nd)))
-   return ERR_PTR(-ECHILD);
+   error = nd_jump_root(nd);
+   if (unlikely(error))
+   return ERR_PTR(error);
while (unlikely(*++res == '/'))
;
}
@@ -1245,12 +1251,16 @@ static int follow_managed(struct path *path, struct 
nameidata *nd)
break;
}
 
-   if (need_mntput && path->mnt == mnt)
-   mntput(path->mnt);
+   if (need_mntput) {
+   if (path->mnt == mnt)
+   mntput(path->mnt);
+   if (unlikely(nd->flags & LOOKUP_NO_JUMPS))
+   ret = -ELOOP;
+   else
+   nd->flags |= LOOKUP_JUMPED;
+   }
if (ret == -EISDIR || !ret)
ret = 1;
-   if (need_mntput)
-   nd->flags |= LOOKUP_JUMPED;
if (unlikely(ret < 0))
path_put_conditional(path, nd);
return ret;
@@ -1307,6 +1317,8 @@ static bool __follow_mount_rcu(struct nameidata *nd, 
struct path *path,
mounted = __lookup_mnt(path->mnt, path->dentry);
if (!mounted)
break;
+   if (unlikely(nd->flags & LOOKUP_NO_JUMPS))
+   return false;
path->mnt = >mnt;
path->dentry = mounted->mnt.mnt_root;
nd->flags |= LOOKUP_JUMPED;
@@ -1327,8 +1339,11 @@ static int follow_dotdot_rcu(struct nameidata *nd)
struct inode *inode = nd->inode;
 
while (1) {
-   if (path_equal(>path, >root))
+   if (unlikely(path_equal(>path, >root))) {
+   if (nd->flags & LOOKUP_NO_JUMPS)
+   return -ELOOP;
break;
+   }
if (nd->path.dentry != nd->path.mnt->mnt_root) {
struct dentry *old = nd->path.dentry;
struct dentry *parent = old->d_parent;
@@ -1455,8 +1470,9 @@ static int path_parent_directory(struct path *path)
 static int follow_dotdot(struct nameidata *nd)
 {
while(1) {
-   if (nd->path.dentry == nd->root.dentry &&
-   nd->path.mnt == nd->root.mnt) {
+   if (unlikely(path_equal(>path, >root))) {
+   if (nd->flags & LOOKUP_NO_JUMPS)
+   return -ELOOP;
break;
}
if (nd->path.dentry != nd->path.mnt->mnt_root) {
@@ -2177,14 +2193,16 @@ static const char *path_init(struct nameidata *nd, 
unsigned flags)
 
nd->m_seq = read_seqbegin(_lock);
if (*s == '/') {
+  

[PATCH] power: ab8500_charger: fix spelling mistake: "prechage" -> "precharge"

[Colin King]

From: Colin Ian King 

trivial fix to spelling mistake in dev_error message.

Signed-off-by: Colin Ian King 
---
 drivers/power/supply/ab8500_charger.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/power/supply/ab8500_charger.c 
b/drivers/power/supply/ab8500_charger.c
index 5cee9aa87aa3..4ebbcce45c48 100644
--- a/drivers/power/supply/ab8500_charger.c
+++ b/drivers/power/supply/ab8500_charger.c
@@ -3238,7 +3238,7 @@ static int ab8500_charger_init_hw_registers(struct 
ab8500_charger *di)
BUS_PP_PRECHG_CURRENT_MASK, 0);
if (ret) {
dev_err(di->dev,
-   "failed to setup usb power path prechage 
current\n");
+   "failed to setup usb power path precharge 
current\n");
goto out;
}
}
-- 
2.11.0

[PATCH] power: ab8500_charger: fix spelling mistake: "prechage" -> "precharge"

[Colin King]

From: Colin Ian King 

trivial fix to spelling mistake in dev_error message.

Signed-off-by: Colin Ian King 
---
 drivers/power/supply/ab8500_charger.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/power/supply/ab8500_charger.c 
b/drivers/power/supply/ab8500_charger.c
index 5cee9aa87aa3..4ebbcce45c48 100644
--- a/drivers/power/supply/ab8500_charger.c
+++ b/drivers/power/supply/ab8500_charger.c
@@ -3238,7 +3238,7 @@ static int ab8500_charger_init_hw_registers(struct 
ab8500_charger *di)
BUS_PP_PRECHG_CURRENT_MASK, 0);
if (ret) {
dev_err(di->dev,
-   "failed to setup usb power path prechage 
current\n");
+   "failed to setup usb power path precharge 
current\n");
goto out;
}
}
-- 
2.11.0

Re: [PATCH] scsi: megaraid_sas: fix spelling mistakes: "outstanding" -> "outstanding"

[Joe Perches]

I did a double-take on the subject line:

"outstanding" -> "outstanding"

Re: [PATCH] scsi: megaraid_sas: fix spelling mistakes: "outstanding" -> "outstanding"

[Joe Perches]

I did a double-take on the subject line:

"outstanding" -> "outstanding"

[PATCH] ALSA: ali5451: fix spelling mistake in "ali_capture_preapre"

[Colin King]

From: Colin Ian King 

trivial fix to spelling mistake in dev_warn message,
"ali_capture_preapre" should be "ali_capture_prepare"

Signed-off-by: Colin Ian King 
---
 sound/pci/ali5451/ali5451.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/pci/ali5451/ali5451.c b/sound/pci/ali5451/ali5451.c
index 92b819e4f729..34bbc2e730a6 100644
--- a/sound/pci/ali5451/ali5451.c
+++ b/sound/pci/ali5451/ali5451.c
@@ -1339,7 +1339,7 @@ static int snd_ali_prepare(struct snd_pcm_substream 
*substream)
rate = snd_ali_get_spdif_in_rate(codec);
if (rate == 0) {
dev_warn(codec->card->dev,
-"ali_capture_preapre: spdif rate detect 
err!\n");
+"ali_capture_prepare: spdif rate detect 
err!\n");
rate = 48000;
}
spin_lock_irq(>reg_lock);
-- 
2.11.0

[PATCH] ALSA: ali5451: fix spelling mistake in "ali_capture_preapre"

[Colin King]

From: Colin Ian King 

trivial fix to spelling mistake in dev_warn message,
"ali_capture_preapre" should be "ali_capture_prepare"

Signed-off-by: Colin Ian King 
---
 sound/pci/ali5451/ali5451.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/pci/ali5451/ali5451.c b/sound/pci/ali5451/ali5451.c
index 92b819e4f729..34bbc2e730a6 100644
--- a/sound/pci/ali5451/ali5451.c
+++ b/sound/pci/ali5451/ali5451.c
@@ -1339,7 +1339,7 @@ static int snd_ali_prepare(struct snd_pcm_substream 
*substream)
rate = snd_ali_get_spdif_in_rate(codec);
if (rate == 0) {
dev_warn(codec->card->dev,
-"ali_capture_preapre: spdif rate detect 
err!\n");
+"ali_capture_prepare: spdif rate detect 
err!\n");
rate = 48000;
}
spin_lock_irq(>reg_lock);
-- 
2.11.0

[PATCH] tracing: fix spelling mistake: "preapre" -> "prepare"

[Colin King]

From: Colin Ian King 

trivial fix to spelling mistake in message.

Signed-off-by: Colin Ian King 
---
 kernel/trace/trace.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index beecf3f67159..76ab1d185322 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -8062,7 +8062,7 @@ __init static int tracer_alloc_buffers(void)
 * buffer. The memory will be removed once the "instance" is removed.
 */
ret = cpuhp_setup_state_multi(CPUHP_TRACE_RB_PREPARE,
- "trace/RB:preapre", trace_rb_cpu_prepare,
+ "trace/RB:prepare", trace_rb_cpu_prepare,
  NULL);
if (ret < 0)
goto out_free_cpumask;
-- 
2.11.0

[PATCH] tracing: fix spelling mistake: "preapre" -> "prepare"

[Colin King]

From: Colin Ian King 

trivial fix to spelling mistake in message.

Signed-off-by: Colin Ian King 
---
 kernel/trace/trace.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index beecf3f67159..76ab1d185322 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -8062,7 +8062,7 @@ __init static int tracer_alloc_buffers(void)
 * buffer. The memory will be removed once the "instance" is removed.
 */
ret = cpuhp_setup_state_multi(CPUHP_TRACE_RB_PREPARE,
- "trace/RB:preapre", trace_rb_cpu_prepare,
+ "trace/RB:prepare", trace_rb_cpu_prepare,
  NULL);
if (ret < 0)
goto out_free_cpumask;
-- 
2.11.0

Re: [patch] timer: Fix timers_update_migration(), and call it in tmigr_init()

[Paul E. McKenney]

On Sat, Apr 29, 2017 at 08:20:33PM +0200, Mike Galbraith wrote:
> On Sat, 2017-04-29 at 11:06 -0700, Paul E. McKenney wrote:
> 
> > If someone will either repost a fresh series or point me at exactly
> > the set of patches to use, I will run it through rcutorture again.
> 
> Patchlet is against x86-tip/master.today.

So today's (as in Saturday April 29) x86-tip/master with the following
patch applied?

Thanx, Paul



timers_update_migration() is called by tick_nohz_activate() before
the late initcall tmigr_init() sets tmigr_enabled to true, resulting
in it updating neither timer_base.nohz_active nor .migration_enabled,
meaning we'll not kick an idling cpu in add_timer_on().

Remove redundant loop avoidance such that tick_nohz_activate() updates
timer_bases[].nohz_active as intended, and call it in tmigr_init() to
update timer_bases[].migration_enabled.

Signed-off-by: Mike Galbraith 
Fixes: ec2206b91d43 timer: Implement the hierarchical pull model
---
 kernel/time/timer.c   |4 
 kernel/time/timer_migration.c |1 +
 2 files changed, 1 insertion(+), 4 deletions(-)

--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -224,10 +224,6 @@ void timers_update_migration(bool update
bool on = sysctl_timer_migration && tick_nohz_active && tmigr_enabled;
unsigned int cpu;

-   /* Avoid the loop, if nothing to update */
-   if (this_cpu_read(timer_bases[BASE_GLOBAL].migration_enabled) == on)
-   return;
-
for_each_possible_cpu(cpu) {
per_cpu(timer_bases[BASE_LOCAL].migration_enabled, cpu) = on;
per_cpu(timer_bases[BASE_GLOBAL].migration_enabled, cpu) = on;
--- a/kernel/time/timer_migration.c
+++ b/kernel/time/timer_migration.c
@@ -649,6 +649,7 @@ static int __init tmigr_init(void)
goto hp_err;

tmigr_enabled = true;
+   timers_update_migration(false);
pr_info("Timer migration: %d hierarchy levels\n", 
tmigr_hierarchy_levels);
return 0;

Re: [patch] timer: Fix timers_update_migration(), and call it in tmigr_init()

[Paul E. McKenney]

On Sat, Apr 29, 2017 at 08:20:33PM +0200, Mike Galbraith wrote:
> On Sat, 2017-04-29 at 11:06 -0700, Paul E. McKenney wrote:
> 
> > If someone will either repost a fresh series or point me at exactly
> > the set of patches to use, I will run it through rcutorture again.
> 
> Patchlet is against x86-tip/master.today.

So today's (as in Saturday April 29) x86-tip/master with the following
patch applied?

Thanx, Paul



timers_update_migration() is called by tick_nohz_activate() before
the late initcall tmigr_init() sets tmigr_enabled to true, resulting
in it updating neither timer_base.nohz_active nor .migration_enabled,
meaning we'll not kick an idling cpu in add_timer_on().

Remove redundant loop avoidance such that tick_nohz_activate() updates
timer_bases[].nohz_active as intended, and call it in tmigr_init() to
update timer_bases[].migration_enabled.

Signed-off-by: Mike Galbraith 
Fixes: ec2206b91d43 timer: Implement the hierarchical pull model
---
 kernel/time/timer.c   |4 
 kernel/time/timer_migration.c |1 +
 2 files changed, 1 insertion(+), 4 deletions(-)

--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -224,10 +224,6 @@ void timers_update_migration(bool update
bool on = sysctl_timer_migration && tick_nohz_active && tmigr_enabled;
unsigned int cpu;

-   /* Avoid the loop, if nothing to update */
-   if (this_cpu_read(timer_bases[BASE_GLOBAL].migration_enabled) == on)
-   return;
-
for_each_possible_cpu(cpu) {
per_cpu(timer_bases[BASE_LOCAL].migration_enabled, cpu) = on;
per_cpu(timer_bases[BASE_GLOBAL].migration_enabled, cpu) = on;
--- a/kernel/time/timer_migration.c
+++ b/kernel/time/timer_migration.c
@@ -649,6 +649,7 @@ static int __init tmigr_init(void)
goto hp_err;

tmigr_enabled = true;
+   timers_update_migration(false);
pr_info("Timer migration: %d hierarchy levels\n", 
tmigr_hierarchy_levels);
return 0;