Re: support for partial irq affinity assignment V3

[Thomas Gleixner]

On Tue, 8 Nov 2016, Jens Axboe wrote:

> On 11/08/2016 06:15 PM, Christoph Hellwig wrote:
> > This series adds support for automatic interrupt assignment to devices
> > that have a few vectors that are set aside for admin or config purposes
> > and thus should not fall into the general per-cpu assginment pool.
> > 
> > The first patch adds that support to the core IRQ and PCI/msi code,
> > and the second is a small tweak to a block layer helper to make use
> > of it.  I'd love to have both go into the same tree so that consumers
> > of this (e.g. the virtio, scsi and rdma trees) only need to pull in
> > one of these trees as dependency.
> 
> Series looks good to me, you can add my Acked-by to all of them.

It's available from

  git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/for-block

for you to pull into the block tree so you can apply the block changes.

Thanks,

tglx

Re: support for partial irq affinity assignment V3

[Thomas Gleixner]

On Tue, 8 Nov 2016, Jens Axboe wrote:

> On 11/08/2016 06:15 PM, Christoph Hellwig wrote:
> > This series adds support for automatic interrupt assignment to devices
> > that have a few vectors that are set aside for admin or config purposes
> > and thus should not fall into the general per-cpu assginment pool.
> > 
> > The first patch adds that support to the core IRQ and PCI/msi code,
> > and the second is a small tweak to a block layer helper to make use
> > of it.  I'd love to have both go into the same tree so that consumers
> > of this (e.g. the virtio, scsi and rdma trees) only need to pull in
> > one of these trees as dependency.
> 
> Series looks good to me, you can add my Acked-by to all of them.

It's available from

  git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/for-block

for you to pull into the block tree so you can apply the block changes.

Thanks,

tglx

RE: [PATCH] mwifiex: printk() overflow with 32-byte SSIDs

[Amitkumar Karwar]

> From: Brian Norris [mailto:briannor...@chromium.org]
> Sent: Wednesday, November 09, 2016 7:58 AM
> To: Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo
> Cc: linux-kernel@vger.kernel.org; linux-wirel...@vger.kernel.org; Cathy
> Luo; secur...@kernel.org; sta...@vger.kernel.org; Brian Norris
> Subject: [PATCH] mwifiex: printk() overflow with 32-byte SSIDs
> 
> SSIDs aren't guaranteed to be 0-terminated. Let's cap the max length
> when we print them out.
> 
> This can be easily noticed by connecting to a network with a 32-octet
> SSID:
> 
> [ 3903.502925] mwifiex_pcie :01:00.0: info: trying to associate to
> '0123456789abcdef0123456789abcdef ' bssid
> xx:xx:xx:xx:xx:xx
> 
> Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell
> mwifiex driver")
> Signed-off-by: Brian Norris 
> Cc: 
> ---
>  drivers/net/wireless/marvell/mwifiex/cfg80211.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> index 39ce76ad00bc..16241d21727b 100644
> --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> @@ -,8 +,9 @@ mwifiex_cfg80211_assoc(struct mwifiex_private
> *priv, size_t ssid_len,
>   is_scanning_required = 1;
>   } else {
>   mwifiex_dbg(priv->adapter, MSG,
> - "info: trying to associate to '%s' bssid
> %pM\n",
> - (char *)req_ssid.ssid, bss->bssid);
> + "info: trying to associate to '%.*s' bssid
> %pM\n",
> + req_ssid.ssid_len, (char *)req_ssid.ssid,
> + bss->bssid);
>   memcpy(>cfg_bssid, bss->bssid, ETH_ALEN);
>   break;
>   }
> @@ -2283,8 +2284,8 @@ mwifiex_cfg80211_connect(struct wiphy *wiphy,
> struct net_device *dev,
>   }
> 
>   mwifiex_dbg(adapter, INFO,
> - "info: Trying to associate to %s and bssid %pM\n",
> - (char *)sme->ssid, sme->bssid);
> + "info: Trying to associate to %.*s and bssid %pM\n",
> + (int)sme->ssid_len, (char *)sme->ssid, sme->bssid);
> 
>   if (!mwifiex_stop_bg_scan(priv))
>   cfg80211_sched_scan_stopped_rtnl(priv->wdev.wiphy);
> @@ -2417,8 +2418,8 @@ mwifiex_cfg80211_join_ibss(struct wiphy *wiphy,
> struct net_device *dev,
>   }
> 
>   mwifiex_dbg(priv->adapter, MSG,
> - "info: trying to join to %s and bssid %pM\n",
> - (char *)params->ssid, params->bssid);
> + "info: trying to join to %.*s and bssid %pM\n",
> + params->ssid_len, (char *)params->ssid, params->bssid);
> 
>   mwifiex_set_ibss_params(priv, params);
> 
> --
> 2.8.0.rc3.226.g39d4020

Thanks for fixing this.

Acked-by: Amitkumar Karwar 

Regards,
Amitkumar

RE: [PATCH] mwifiex: printk() overflow with 32-byte SSIDs

[Amitkumar Karwar]

> From: Brian Norris [mailto:briannor...@chromium.org]
> Sent: Wednesday, November 09, 2016 7:58 AM
> To: Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo
> Cc: linux-kernel@vger.kernel.org; linux-wirel...@vger.kernel.org; Cathy
> Luo; secur...@kernel.org; sta...@vger.kernel.org; Brian Norris
> Subject: [PATCH] mwifiex: printk() overflow with 32-byte SSIDs
> 
> SSIDs aren't guaranteed to be 0-terminated. Let's cap the max length
> when we print them out.
> 
> This can be easily noticed by connecting to a network with a 32-octet
> SSID:
> 
> [ 3903.502925] mwifiex_pcie :01:00.0: info: trying to associate to
> '0123456789abcdef0123456789abcdef ' bssid
> xx:xx:xx:xx:xx:xx
> 
> Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell
> mwifiex driver")
> Signed-off-by: Brian Norris 
> Cc: 
> ---
>  drivers/net/wireless/marvell/mwifiex/cfg80211.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> index 39ce76ad00bc..16241d21727b 100644
> --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> @@ -,8 +,9 @@ mwifiex_cfg80211_assoc(struct mwifiex_private
> *priv, size_t ssid_len,
>   is_scanning_required = 1;
>   } else {
>   mwifiex_dbg(priv->adapter, MSG,
> - "info: trying to associate to '%s' bssid
> %pM\n",
> - (char *)req_ssid.ssid, bss->bssid);
> + "info: trying to associate to '%.*s' bssid
> %pM\n",
> + req_ssid.ssid_len, (char *)req_ssid.ssid,
> + bss->bssid);
>   memcpy(>cfg_bssid, bss->bssid, ETH_ALEN);
>   break;
>   }
> @@ -2283,8 +2284,8 @@ mwifiex_cfg80211_connect(struct wiphy *wiphy,
> struct net_device *dev,
>   }
> 
>   mwifiex_dbg(adapter, INFO,
> - "info: Trying to associate to %s and bssid %pM\n",
> - (char *)sme->ssid, sme->bssid);
> + "info: Trying to associate to %.*s and bssid %pM\n",
> + (int)sme->ssid_len, (char *)sme->ssid, sme->bssid);
> 
>   if (!mwifiex_stop_bg_scan(priv))
>   cfg80211_sched_scan_stopped_rtnl(priv->wdev.wiphy);
> @@ -2417,8 +2418,8 @@ mwifiex_cfg80211_join_ibss(struct wiphy *wiphy,
> struct net_device *dev,
>   }
> 
>   mwifiex_dbg(priv->adapter, MSG,
> - "info: trying to join to %s and bssid %pM\n",
> - (char *)params->ssid, params->bssid);
> + "info: trying to join to %.*s and bssid %pM\n",
> + params->ssid_len, (char *)params->ssid, params->bssid);
> 
>   mwifiex_set_ibss_params(priv, params);
> 
> --
> 2.8.0.rc3.226.g39d4020

Thanks for fixing this.

Acked-by: Amitkumar Karwar 

Regards,
Amitkumar

[tip:irq/core] PCI: Remove the irq_affinity mask from struct pci_dev

[tip-bot for Christoph Hellwig]

Commit-ID:  0cf71b04467bc34063cecae577f12481da6cc565
Gitweb: http://git.kernel.org/tip/0cf71b04467bc34063cecae577f12481da6cc565
Author: Christoph Hellwig 
AuthorDate: Tue, 8 Nov 2016 17:15:06 -0800
Committer:  Thomas Gleixner 
CommitDate: Wed, 9 Nov 2016 08:25:10 +0100

PCI: Remove the irq_affinity mask from struct pci_dev

This has never been used, and now is totally unreferenced.  Nuke it.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Hannes Reinecke 
Reviewed-by: Johannes Thumshirn 
Acked-by: Bjorn Helgaas 
Acked-by: Jens Axboe 
Cc: linux-bl...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Link: http://lkml.kernel.org/r/1478654107-7384-7-git-send-email-...@lst.de
Signed-off-by: Thomas Gleixner 

---
 include/linux/pci.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/linux/pci.h b/include/linux/pci.h
index 7090f5f..f2ba6ac 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -333,7 +333,6 @@ struct pci_dev {
 * directly, use the values stored here. They might be different!
 */
unsigned intirq;
-   struct cpumask  *irq_affinity;
struct resource resource[DEVICE_COUNT_RESOURCE]; /* I/O and memory 
regions + expansion ROMs */
 
bool match_driver;  /* Skip attaching driver */

[tip:irq/core] PCI: Remove the irq_affinity mask from struct pci_dev

[tip-bot for Christoph Hellwig]

Commit-ID:  0cf71b04467bc34063cecae577f12481da6cc565
Gitweb: http://git.kernel.org/tip/0cf71b04467bc34063cecae577f12481da6cc565
Author: Christoph Hellwig 
AuthorDate: Tue, 8 Nov 2016 17:15:06 -0800
Committer:  Thomas Gleixner 
CommitDate: Wed, 9 Nov 2016 08:25:10 +0100

PCI: Remove the irq_affinity mask from struct pci_dev

This has never been used, and now is totally unreferenced.  Nuke it.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Hannes Reinecke 
Reviewed-by: Johannes Thumshirn 
Acked-by: Bjorn Helgaas 
Acked-by: Jens Axboe 
Cc: linux-bl...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Link: http://lkml.kernel.org/r/1478654107-7384-7-git-send-email-...@lst.de
Signed-off-by: Thomas Gleixner 

---
 include/linux/pci.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/linux/pci.h b/include/linux/pci.h
index 7090f5f..f2ba6ac 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -333,7 +333,6 @@ struct pci_dev {
 * directly, use the values stored here. They might be different!
 */
unsigned intirq;
-   struct cpumask  *irq_affinity;
struct resource resource[DEVICE_COUNT_RESOURCE]; /* I/O and memory 
regions + expansion ROMs */
 
bool match_driver;  /* Skip attaching driver */

[tip:irq/core] PCI/MSI: Provide pci_alloc_irq_vectors_affinity()

[tip-bot for Christoph Hellwig]

Commit-ID:  402723ad5c625ee052432698ae5e56b02d38d4ec
Gitweb: http://git.kernel.org/tip/402723ad5c625ee052432698ae5e56b02d38d4ec
Author: Christoph Hellwig 
AuthorDate: Tue, 8 Nov 2016 17:15:05 -0800
Committer:  Thomas Gleixner 
CommitDate: Wed, 9 Nov 2016 08:25:10 +0100

PCI/MSI: Provide pci_alloc_irq_vectors_affinity()

This is a variant of pci_alloc_irq_vectors() that allows passing a struct
irq_affinity to provide fine-grained IRQ affinity control.

For now this means being able to exclude vectors at the beginning or end of
the MSI vector space, but it could also be used for any other quirks needed
in the future (e.g. more vectors than CPUs, or excluding CPUs from the
spreading).

Signed-off-by: Christoph Hellwig 
Reviewed-by: Hannes Reinecke 
Reviewed-by: Johannes Thumshirn 
Acked-by: Bjorn Helgaas 
Acked-by: Jens Axboe 
Cc: linux-bl...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Link: http://lkml.kernel.org/r/1478654107-7384-6-git-send-email-...@lst.de
Signed-off-by: Thomas Gleixner 

---
 drivers/pci/msi.c   | 20 +---
 include/linux/pci.h | 24 +++-
 2 files changed, 32 insertions(+), 12 deletions(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 512f388..dd27f73 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -1179,11 +1179,12 @@ int pci_enable_msix_range(struct pci_dev *dev, struct 
msix_entry *entries,
 EXPORT_SYMBOL(pci_enable_msix_range);
 
 /**
- * pci_alloc_irq_vectors - allocate multiple IRQs for a device
+ * pci_alloc_irq_vectors_affinity - allocate multiple IRQs for a device
  * @dev:   PCI device to operate on
  * @min_vecs:  minimum number of vectors required (must be >= 1)
  * @max_vecs:  maximum (desired) number of vectors
  * @flags: flags or quirks for the allocation
+ * @affd:  optional description of the affinity requirements
  *
  * Allocate up to @max_vecs interrupt vectors for @dev, using MSI-X or MSI
  * vectors if available, and fall back to a single legacy vector
@@ -1195,15 +1196,20 @@ EXPORT_SYMBOL(pci_enable_msix_range);
  * To get the Linux IRQ number used for a vector that can be passed to
  * request_irq() use the pci_irq_vector() helper.
  */
-int pci_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,
-   unsigned int max_vecs, unsigned int flags)
+int pci_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,
+  unsigned int max_vecs, unsigned int flags,
+  const struct irq_affinity *affd)
 {
static const struct irq_affinity msi_default_affd;
-   const struct irq_affinity *affd = NULL;
int vecs = -ENOSPC;
 
-   if (flags & PCI_IRQ_AFFINITY)
-   affd = _default_affd;
+   if (flags & PCI_IRQ_AFFINITY) {
+   if (!affd)
+   affd = _default_affd;
+   } else {
+   if (WARN_ON(affd))
+   affd = NULL;
+   }
 
if (flags & PCI_IRQ_MSIX) {
vecs = __pci_enable_msix_range(dev, NULL, min_vecs, max_vecs,
@@ -1226,7 +1232,7 @@ int pci_alloc_irq_vectors(struct pci_dev *dev, unsigned 
int min_vecs,
 
return vecs;
 }
-EXPORT_SYMBOL(pci_alloc_irq_vectors);
+EXPORT_SYMBOL(pci_alloc_irq_vectors_affinity);
 
 /**
  * pci_free_irq_vectors - free previously allocated IRQs for a device
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 0e49f70..7090f5f 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -244,6 +244,7 @@ struct pci_cap_saved_state {
struct pci_cap_saved_data cap;
 };
 
+struct irq_affinity;
 struct pcie_link_state;
 struct pci_vpd;
 struct pci_sriov;
@@ -1310,8 +1311,10 @@ static inline int pci_enable_msix_exact(struct pci_dev 
*dev,
return rc;
return 0;
 }
-int pci_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,
-   unsigned int max_vecs, unsigned int flags);
+int pci_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,
+  unsigned int max_vecs, unsigned int flags,
+  const struct irq_affinity *affd);
+
 void pci_free_irq_vectors(struct pci_dev *dev);
 int pci_irq_vector(struct pci_dev *dev, unsigned int nr);
 const struct cpumask *pci_irq_get_affinity(struct pci_dev *pdev, int vec);
@@ -1339,14 +1342,17 @@ static inline int pci_enable_msix_range(struct pci_dev 
*dev,
 static inline int pci_enable_msix_exact(struct pci_dev *dev,
  struct msix_entry *entries, int nvec)
 { return -ENOSYS; }
-static inline int pci_alloc_irq_vectors(struct pci_dev *dev,
-   unsigned int min_vecs, unsigned int max_vecs,
-   unsigned int flags)
+
+static inline int
+pci_alloc_irq_vectors_affinity(struct 

[tip:irq/core] PCI/MSI: Provide pci_alloc_irq_vectors_affinity()

[tip-bot for Christoph Hellwig]

Commit-ID:  402723ad5c625ee052432698ae5e56b02d38d4ec
Gitweb: http://git.kernel.org/tip/402723ad5c625ee052432698ae5e56b02d38d4ec
Author: Christoph Hellwig 
AuthorDate: Tue, 8 Nov 2016 17:15:05 -0800
Committer:  Thomas Gleixner 
CommitDate: Wed, 9 Nov 2016 08:25:10 +0100

PCI/MSI: Provide pci_alloc_irq_vectors_affinity()

This is a variant of pci_alloc_irq_vectors() that allows passing a struct
irq_affinity to provide fine-grained IRQ affinity control.

For now this means being able to exclude vectors at the beginning or end of
the MSI vector space, but it could also be used for any other quirks needed
in the future (e.g. more vectors than CPUs, or excluding CPUs from the
spreading).

Signed-off-by: Christoph Hellwig 
Reviewed-by: Hannes Reinecke 
Reviewed-by: Johannes Thumshirn 
Acked-by: Bjorn Helgaas 
Acked-by: Jens Axboe 
Cc: linux-bl...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Link: http://lkml.kernel.org/r/1478654107-7384-6-git-send-email-...@lst.de
Signed-off-by: Thomas Gleixner 

---
 drivers/pci/msi.c   | 20 +---
 include/linux/pci.h | 24 +++-
 2 files changed, 32 insertions(+), 12 deletions(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 512f388..dd27f73 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -1179,11 +1179,12 @@ int pci_enable_msix_range(struct pci_dev *dev, struct 
msix_entry *entries,
 EXPORT_SYMBOL(pci_enable_msix_range);
 
 /**
- * pci_alloc_irq_vectors - allocate multiple IRQs for a device
+ * pci_alloc_irq_vectors_affinity - allocate multiple IRQs for a device
  * @dev:   PCI device to operate on
  * @min_vecs:  minimum number of vectors required (must be >= 1)
  * @max_vecs:  maximum (desired) number of vectors
  * @flags: flags or quirks for the allocation
+ * @affd:  optional description of the affinity requirements
  *
  * Allocate up to @max_vecs interrupt vectors for @dev, using MSI-X or MSI
  * vectors if available, and fall back to a single legacy vector
@@ -1195,15 +1196,20 @@ EXPORT_SYMBOL(pci_enable_msix_range);
  * To get the Linux IRQ number used for a vector that can be passed to
  * request_irq() use the pci_irq_vector() helper.
  */
-int pci_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,
-   unsigned int max_vecs, unsigned int flags)
+int pci_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,
+  unsigned int max_vecs, unsigned int flags,
+  const struct irq_affinity *affd)
 {
static const struct irq_affinity msi_default_affd;
-   const struct irq_affinity *affd = NULL;
int vecs = -ENOSPC;
 
-   if (flags & PCI_IRQ_AFFINITY)
-   affd = _default_affd;
+   if (flags & PCI_IRQ_AFFINITY) {
+   if (!affd)
+   affd = _default_affd;
+   } else {
+   if (WARN_ON(affd))
+   affd = NULL;
+   }
 
if (flags & PCI_IRQ_MSIX) {
vecs = __pci_enable_msix_range(dev, NULL, min_vecs, max_vecs,
@@ -1226,7 +1232,7 @@ int pci_alloc_irq_vectors(struct pci_dev *dev, unsigned 
int min_vecs,
 
return vecs;
 }
-EXPORT_SYMBOL(pci_alloc_irq_vectors);
+EXPORT_SYMBOL(pci_alloc_irq_vectors_affinity);
 
 /**
  * pci_free_irq_vectors - free previously allocated IRQs for a device
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 0e49f70..7090f5f 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -244,6 +244,7 @@ struct pci_cap_saved_state {
struct pci_cap_saved_data cap;
 };
 
+struct irq_affinity;
 struct pcie_link_state;
 struct pci_vpd;
 struct pci_sriov;
@@ -1310,8 +1311,10 @@ static inline int pci_enable_msix_exact(struct pci_dev 
*dev,
return rc;
return 0;
 }
-int pci_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,
-   unsigned int max_vecs, unsigned int flags);
+int pci_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,
+  unsigned int max_vecs, unsigned int flags,
+  const struct irq_affinity *affd);
+
 void pci_free_irq_vectors(struct pci_dev *dev);
 int pci_irq_vector(struct pci_dev *dev, unsigned int nr);
 const struct cpumask *pci_irq_get_affinity(struct pci_dev *pdev, int vec);
@@ -1339,14 +1342,17 @@ static inline int pci_enable_msix_range(struct pci_dev 
*dev,
 static inline int pci_enable_msix_exact(struct pci_dev *dev,
  struct msix_entry *entries, int nvec)
 { return -ENOSYS; }
-static inline int pci_alloc_irq_vectors(struct pci_dev *dev,
-   unsigned int min_vecs, unsigned int max_vecs,
-   unsigned int flags)
+
+static inline int
+pci_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,
+  unsigned int max_vecs, unsigned int flags,
+  

[tip:irq/core] PCI/MSI: Propagate IRQ affinity description through the MSI code

[tip-bot for Christoph Hellwig]

Commit-ID:  61e1c5905290efe48bacda5e342d4af4cb1b923b
Gitweb: http://git.kernel.org/tip/61e1c5905290efe48bacda5e342d4af4cb1b923b
Author: Christoph Hellwig 
AuthorDate: Tue, 8 Nov 2016 17:15:04 -0800
Committer:  Thomas Gleixner 
CommitDate: Wed, 9 Nov 2016 08:25:09 +0100

PCI/MSI: Propagate IRQ affinity description through the MSI code

No API change yet, just pass it down all the way from
pci_alloc_irq_vectors() to the core MSI code.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Hannes Reinecke 
Reviewed-by: Johannes Thumshirn 
Acked-by: Bjorn Helgaas 
Acked-by: Jens Axboe 
Cc: linux-bl...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Link: http://lkml.kernel.org/r/1478654107-7384-5-git-send-email-...@lst.de
Signed-off-by: Thomas Gleixner 

---
 drivers/pci/msi.c | 66 +++
 1 file changed, 33 insertions(+), 33 deletions(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index f4a108b..512f388 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -551,15 +551,14 @@ error_attrs:
 }
 
 static struct msi_desc *
-msi_setup_entry(struct pci_dev *dev, int nvec, bool affinity)
+msi_setup_entry(struct pci_dev *dev, int nvec, const struct irq_affinity *affd)
 {
-   static const struct irq_affinity default_affd;
struct cpumask *masks = NULL;
struct msi_desc *entry;
u16 control;
 
-   if (affinity) {
-   masks = irq_create_affinity_masks(nvec, _affd);
+   if (affd) {
+   masks = irq_create_affinity_masks(nvec, affd);
if (!masks)
pr_err("Unable to allocate affinity masks, ignoring\n");
}
@@ -619,7 +618,8 @@ static int msi_verify_entries(struct pci_dev *dev)
  * an error, and a positive return value indicates the number of interrupts
  * which could have been allocated.
  */
-static int msi_capability_init(struct pci_dev *dev, int nvec, bool affinity)
+static int msi_capability_init(struct pci_dev *dev, int nvec,
+  const struct irq_affinity *affd)
 {
struct msi_desc *entry;
int ret;
@@ -627,7 +627,7 @@ static int msi_capability_init(struct pci_dev *dev, int 
nvec, bool affinity)
 
pci_msi_set_enable(dev, 0); /* Disable MSI during set up */
 
-   entry = msi_setup_entry(dev, nvec, affinity);
+   entry = msi_setup_entry(dev, nvec, affd);
if (!entry)
return -ENOMEM;
 
@@ -691,15 +691,14 @@ static void __iomem *msix_map_region(struct pci_dev *dev, 
unsigned nr_entries)
 
 static int msix_setup_entries(struct pci_dev *dev, void __iomem *base,
  struct msix_entry *entries, int nvec,
- bool affinity)
+ const struct irq_affinity *affd)
 {
-   static const struct irq_affinity default_affd;
struct cpumask *curmsk, *masks = NULL;
struct msi_desc *entry;
int ret, i;
 
-   if (affinity) {
-   masks = irq_create_affinity_masks(nvec, _affd);
+   if (affd) {
+   masks = irq_create_affinity_masks(nvec, affd);
if (!masks)
pr_err("Unable to allocate affinity masks, ignoring\n");
}
@@ -755,14 +754,14 @@ static void msix_program_entries(struct pci_dev *dev,
  * @dev: pointer to the pci_dev data structure of MSI-X device function
  * @entries: pointer to an array of struct msix_entry entries
  * @nvec: number of @entries
- * @affinity: flag to indicate cpu irq affinity mask should be set
+ * @affd: Optional pointer to enable automatic affinity assignement
  *
  * Setup the MSI-X capability structure of device function with a
  * single MSI-X irq. A return of zero indicates the successful setup of
  * requested MSI-X entries with allocated irqs or non-zero for otherwise.
  **/
 static int msix_capability_init(struct pci_dev *dev, struct msix_entry 
*entries,
-   int nvec, bool affinity)
+   int nvec, const struct irq_affinity *affd)
 {
int ret;
u16 control;
@@ -777,7 +776,7 @@ static int msix_capability_init(struct pci_dev *dev, struct 
msix_entry *entries,
if (!base)
return -ENOMEM;
 
-   ret = msix_setup_entries(dev, base, entries, nvec, affinity);
+   ret = msix_setup_entries(dev, base, entries, nvec, affd);
if (ret)
return ret;
 
@@ -958,7 +957,7 @@ int pci_msix_vec_count(struct pci_dev *dev)
 EXPORT_SYMBOL(pci_msix_vec_count);
 
 static int __pci_enable_msix(struct pci_dev *dev, struct msix_entry *entries,
-int nvec, bool affinity)
+int nvec, const struct irq_affinity *affd)
 {
int nr_entries;
int i, j;
@@ -990,7 +989,7 @@ static int 

[tip:irq/core] genirq/affinity: Handle pre/post vectors in irq_create_affinity_masks()

[tip-bot for Christoph Hellwig]

Commit-ID:  67c93c218dc5d1b45d547771f1fdb44a381e1faf
Gitweb: http://git.kernel.org/tip/67c93c218dc5d1b45d547771f1fdb44a381e1faf
Author: Christoph Hellwig 
AuthorDate: Tue, 8 Nov 2016 17:15:03 -0800
Committer:  Thomas Gleixner 
CommitDate: Wed, 9 Nov 2016 08:25:09 +0100

genirq/affinity: Handle pre/post vectors in irq_create_affinity_masks()

Only calculate the affinity for the main I/O vectors, and skip the
pre or post vectors specified by struct irq_affinity.

Also remove the irq_affinity cpumask argument that has never been used.
If we ever need it in the future we can pass it through struct
irq_affinity.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Hannes Reinecke 
Acked-by: Bjorn Helgaas 
Acked-by: Jens Axboe 
Cc: linux-bl...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Link: http://lkml.kernel.org/r/1478654107-7384-4-git-send-email-...@lst.de
Signed-off-by: Thomas Gleixner 

---
 drivers/pci/msi.c |  6 --
 include/linux/interrupt.h |  4 ++--
 kernel/irq/affinity.c | 46 +-
 3 files changed, 31 insertions(+), 25 deletions(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index dad2da7..f4a108b 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -553,12 +553,13 @@ error_attrs:
 static struct msi_desc *
 msi_setup_entry(struct pci_dev *dev, int nvec, bool affinity)
 {
+   static const struct irq_affinity default_affd;
struct cpumask *masks = NULL;
struct msi_desc *entry;
u16 control;
 
if (affinity) {
-   masks = irq_create_affinity_masks(dev->irq_affinity, nvec);
+   masks = irq_create_affinity_masks(nvec, _affd);
if (!masks)
pr_err("Unable to allocate affinity masks, ignoring\n");
}
@@ -692,12 +693,13 @@ static int msix_setup_entries(struct pci_dev *dev, void 
__iomem *base,
  struct msix_entry *entries, int nvec,
  bool affinity)
 {
+   static const struct irq_affinity default_affd;
struct cpumask *curmsk, *masks = NULL;
struct msi_desc *entry;
int ret, i;
 
if (affinity) {
-   masks = irq_create_affinity_masks(dev->irq_affinity, nvec);
+   masks = irq_create_affinity_masks(nvec, _affd);
if (!masks)
pr_err("Unable to allocate affinity masks, ignoring\n");
}
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 9081f23..53144e7 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -290,7 +290,7 @@ extern int irq_set_affinity_hint(unsigned int irq, const 
struct cpumask *m);
 extern int
 irq_set_affinity_notifier(unsigned int irq, struct irq_affinity_notify 
*notify);
 
-struct cpumask *irq_create_affinity_masks(const struct cpumask *affinity, int 
nvec);
+struct cpumask *irq_create_affinity_masks(int nvec, const struct irq_affinity 
*affd);
 int irq_calc_affinity_vectors(int maxvec, const struct irq_affinity *affd);
 
 #else /* CONFIG_SMP */
@@ -325,7 +325,7 @@ irq_set_affinity_notifier(unsigned int irq, struct 
irq_affinity_notify *notify)
 }
 
 static inline struct cpumask *
-irq_create_affinity_masks(const struct cpumask *affinity, int nvec)
+irq_create_affinity_masks(int nvec, const struct irq_affinity *affd)
 {
return NULL;
 }
diff --git a/kernel/irq/affinity.c b/kernel/irq/affinity.c
index 8d92597..17360bd 100644
--- a/kernel/irq/affinity.c
+++ b/kernel/irq/affinity.c
@@ -51,16 +51,16 @@ static int get_nodes_in_cpumask(const struct cpumask *mask, 
nodemask_t *nodemsk)
 
 /**
  * irq_create_affinity_masks - Create affinity masks for multiqueue spreading
- * @affinity:  The affinity mask to spread. If NULL cpu_online_mask
- * is used
- * @nvecs: The number of vectors
+ * @nvecs: The total number of vectors
+ * @affd:  Description of the affinity requirements
  *
  * Returns the masks pointer or NULL if allocation failed.
  */
-struct cpumask *irq_create_affinity_masks(const struct cpumask *affinity,
- int nvec)
+struct cpumask *
+irq_create_affinity_masks(int nvecs, const struct irq_affinity *affd)
 {
-   int n, nodes, vecs_per_node, cpus_per_vec, extra_vecs, curvec = 0;
+   int n, nodes, vecs_per_node, cpus_per_vec, extra_vecs, curvec;
+   int affv = nvecs - affd->pre_vectors - affd->post_vectors;
nodemask_t nodemsk = NODE_MASK_NONE;
struct cpumask *masks;
cpumask_var_t nmsk;
@@ -68,46 +68,46 @@ struct cpumask *irq_create_affinity_masks(const struct 
cpumask *affinity,
if (!zalloc_cpumask_var(, GFP_KERNEL))
return NULL;
 
-   masks = kzalloc(nvec * sizeof(*masks), GFP_KERNEL);
+   masks = kcalloc(nvecs, sizeof(*masks), GFP_KERNEL);
  

[tip:irq/core] PCI/MSI: Propagate IRQ affinity description through the MSI code

[tip-bot for Christoph Hellwig]

Commit-ID:  61e1c5905290efe48bacda5e342d4af4cb1b923b
Gitweb: http://git.kernel.org/tip/61e1c5905290efe48bacda5e342d4af4cb1b923b
Author: Christoph Hellwig 
AuthorDate: Tue, 8 Nov 2016 17:15:04 -0800
Committer:  Thomas Gleixner 
CommitDate: Wed, 9 Nov 2016 08:25:09 +0100

PCI/MSI: Propagate IRQ affinity description through the MSI code

No API change yet, just pass it down all the way from
pci_alloc_irq_vectors() to the core MSI code.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Hannes Reinecke 
Reviewed-by: Johannes Thumshirn 
Acked-by: Bjorn Helgaas 
Acked-by: Jens Axboe 
Cc: linux-bl...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Link: http://lkml.kernel.org/r/1478654107-7384-5-git-send-email-...@lst.de
Signed-off-by: Thomas Gleixner 

---
 drivers/pci/msi.c | 66 +++
 1 file changed, 33 insertions(+), 33 deletions(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index f4a108b..512f388 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -551,15 +551,14 @@ error_attrs:
 }
 
 static struct msi_desc *
-msi_setup_entry(struct pci_dev *dev, int nvec, bool affinity)
+msi_setup_entry(struct pci_dev *dev, int nvec, const struct irq_affinity *affd)
 {
-   static const struct irq_affinity default_affd;
struct cpumask *masks = NULL;
struct msi_desc *entry;
u16 control;
 
-   if (affinity) {
-   masks = irq_create_affinity_masks(nvec, _affd);
+   if (affd) {
+   masks = irq_create_affinity_masks(nvec, affd);
if (!masks)
pr_err("Unable to allocate affinity masks, ignoring\n");
}
@@ -619,7 +618,8 @@ static int msi_verify_entries(struct pci_dev *dev)
  * an error, and a positive return value indicates the number of interrupts
  * which could have been allocated.
  */
-static int msi_capability_init(struct pci_dev *dev, int nvec, bool affinity)
+static int msi_capability_init(struct pci_dev *dev, int nvec,
+  const struct irq_affinity *affd)
 {
struct msi_desc *entry;
int ret;
@@ -627,7 +627,7 @@ static int msi_capability_init(struct pci_dev *dev, int 
nvec, bool affinity)
 
pci_msi_set_enable(dev, 0); /* Disable MSI during set up */
 
-   entry = msi_setup_entry(dev, nvec, affinity);
+   entry = msi_setup_entry(dev, nvec, affd);
if (!entry)
return -ENOMEM;
 
@@ -691,15 +691,14 @@ static void __iomem *msix_map_region(struct pci_dev *dev, 
unsigned nr_entries)
 
 static int msix_setup_entries(struct pci_dev *dev, void __iomem *base,
  struct msix_entry *entries, int nvec,
- bool affinity)
+ const struct irq_affinity *affd)
 {
-   static const struct irq_affinity default_affd;
struct cpumask *curmsk, *masks = NULL;
struct msi_desc *entry;
int ret, i;
 
-   if (affinity) {
-   masks = irq_create_affinity_masks(nvec, _affd);
+   if (affd) {
+   masks = irq_create_affinity_masks(nvec, affd);
if (!masks)
pr_err("Unable to allocate affinity masks, ignoring\n");
}
@@ -755,14 +754,14 @@ static void msix_program_entries(struct pci_dev *dev,
  * @dev: pointer to the pci_dev data structure of MSI-X device function
  * @entries: pointer to an array of struct msix_entry entries
  * @nvec: number of @entries
- * @affinity: flag to indicate cpu irq affinity mask should be set
+ * @affd: Optional pointer to enable automatic affinity assignement
  *
  * Setup the MSI-X capability structure of device function with a
  * single MSI-X irq. A return of zero indicates the successful setup of
  * requested MSI-X entries with allocated irqs or non-zero for otherwise.
  **/
 static int msix_capability_init(struct pci_dev *dev, struct msix_entry 
*entries,
-   int nvec, bool affinity)
+   int nvec, const struct irq_affinity *affd)
 {
int ret;
u16 control;
@@ -777,7 +776,7 @@ static int msix_capability_init(struct pci_dev *dev, struct 
msix_entry *entries,
if (!base)
return -ENOMEM;
 
-   ret = msix_setup_entries(dev, base, entries, nvec, affinity);
+   ret = msix_setup_entries(dev, base, entries, nvec, affd);
if (ret)
return ret;
 
@@ -958,7 +957,7 @@ int pci_msix_vec_count(struct pci_dev *dev)
 EXPORT_SYMBOL(pci_msix_vec_count);
 
 static int __pci_enable_msix(struct pci_dev *dev, struct msix_entry *entries,
-int nvec, bool affinity)
+int nvec, const struct irq_affinity *affd)
 {
int nr_entries;
int i, j;
@@ -990,7 +989,7 @@ static int __pci_enable_msix(struct pci_dev *dev, struct 
msix_entry *entries,
dev_info(>dev, "can't enable MSI-X (MSI IRQ already 
assigned)\n");
  

[tip:irq/core] genirq/affinity: Handle pre/post vectors in irq_create_affinity_masks()

[tip-bot for Christoph Hellwig]

Commit-ID:  67c93c218dc5d1b45d547771f1fdb44a381e1faf
Gitweb: http://git.kernel.org/tip/67c93c218dc5d1b45d547771f1fdb44a381e1faf
Author: Christoph Hellwig 
AuthorDate: Tue, 8 Nov 2016 17:15:03 -0800
Committer:  Thomas Gleixner 
CommitDate: Wed, 9 Nov 2016 08:25:09 +0100

genirq/affinity: Handle pre/post vectors in irq_create_affinity_masks()

Only calculate the affinity for the main I/O vectors, and skip the
pre or post vectors specified by struct irq_affinity.

Also remove the irq_affinity cpumask argument that has never been used.
If we ever need it in the future we can pass it through struct
irq_affinity.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Hannes Reinecke 
Acked-by: Bjorn Helgaas 
Acked-by: Jens Axboe 
Cc: linux-bl...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Link: http://lkml.kernel.org/r/1478654107-7384-4-git-send-email-...@lst.de
Signed-off-by: Thomas Gleixner 

---
 drivers/pci/msi.c |  6 --
 include/linux/interrupt.h |  4 ++--
 kernel/irq/affinity.c | 46 +-
 3 files changed, 31 insertions(+), 25 deletions(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index dad2da7..f4a108b 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -553,12 +553,13 @@ error_attrs:
 static struct msi_desc *
 msi_setup_entry(struct pci_dev *dev, int nvec, bool affinity)
 {
+   static const struct irq_affinity default_affd;
struct cpumask *masks = NULL;
struct msi_desc *entry;
u16 control;
 
if (affinity) {
-   masks = irq_create_affinity_masks(dev->irq_affinity, nvec);
+   masks = irq_create_affinity_masks(nvec, _affd);
if (!masks)
pr_err("Unable to allocate affinity masks, ignoring\n");
}
@@ -692,12 +693,13 @@ static int msix_setup_entries(struct pci_dev *dev, void 
__iomem *base,
  struct msix_entry *entries, int nvec,
  bool affinity)
 {
+   static const struct irq_affinity default_affd;
struct cpumask *curmsk, *masks = NULL;
struct msi_desc *entry;
int ret, i;
 
if (affinity) {
-   masks = irq_create_affinity_masks(dev->irq_affinity, nvec);
+   masks = irq_create_affinity_masks(nvec, _affd);
if (!masks)
pr_err("Unable to allocate affinity masks, ignoring\n");
}
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 9081f23..53144e7 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -290,7 +290,7 @@ extern int irq_set_affinity_hint(unsigned int irq, const 
struct cpumask *m);
 extern int
 irq_set_affinity_notifier(unsigned int irq, struct irq_affinity_notify 
*notify);
 
-struct cpumask *irq_create_affinity_masks(const struct cpumask *affinity, int 
nvec);
+struct cpumask *irq_create_affinity_masks(int nvec, const struct irq_affinity 
*affd);
 int irq_calc_affinity_vectors(int maxvec, const struct irq_affinity *affd);
 
 #else /* CONFIG_SMP */
@@ -325,7 +325,7 @@ irq_set_affinity_notifier(unsigned int irq, struct 
irq_affinity_notify *notify)
 }
 
 static inline struct cpumask *
-irq_create_affinity_masks(const struct cpumask *affinity, int nvec)
+irq_create_affinity_masks(int nvec, const struct irq_affinity *affd)
 {
return NULL;
 }
diff --git a/kernel/irq/affinity.c b/kernel/irq/affinity.c
index 8d92597..17360bd 100644
--- a/kernel/irq/affinity.c
+++ b/kernel/irq/affinity.c
@@ -51,16 +51,16 @@ static int get_nodes_in_cpumask(const struct cpumask *mask, 
nodemask_t *nodemsk)
 
 /**
  * irq_create_affinity_masks - Create affinity masks for multiqueue spreading
- * @affinity:  The affinity mask to spread. If NULL cpu_online_mask
- * is used
- * @nvecs: The number of vectors
+ * @nvecs: The total number of vectors
+ * @affd:  Description of the affinity requirements
  *
  * Returns the masks pointer or NULL if allocation failed.
  */
-struct cpumask *irq_create_affinity_masks(const struct cpumask *affinity,
- int nvec)
+struct cpumask *
+irq_create_affinity_masks(int nvecs, const struct irq_affinity *affd)
 {
-   int n, nodes, vecs_per_node, cpus_per_vec, extra_vecs, curvec = 0;
+   int n, nodes, vecs_per_node, cpus_per_vec, extra_vecs, curvec;
+   int affv = nvecs - affd->pre_vectors - affd->post_vectors;
nodemask_t nodemsk = NODE_MASK_NONE;
struct cpumask *masks;
cpumask_var_t nmsk;
@@ -68,46 +68,46 @@ struct cpumask *irq_create_affinity_masks(const struct 
cpumask *affinity,
if (!zalloc_cpumask_var(, GFP_KERNEL))
return NULL;
 
-   masks = kzalloc(nvec * sizeof(*masks), GFP_KERNEL);
+   masks = kcalloc(nvecs, sizeof(*masks), GFP_KERNEL);
if (!masks)
goto out;
 
+   /* Fill out vectors at the beginning that don't need affinity */

[tip:irq/core] genirq/affinity: Handle pre/post vectors in irq_calc_affinity_vectors()

[tip-bot for Christoph Hellwig]

Commit-ID:  212bd846223c718b6577d4df16fd8d05a55ad914
Gitweb: http://git.kernel.org/tip/212bd846223c718b6577d4df16fd8d05a55ad914
Author: Christoph Hellwig 
AuthorDate: Tue, 8 Nov 2016 17:15:02 -0800
Committer:  Thomas Gleixner 
CommitDate: Wed, 9 Nov 2016 08:25:08 +0100

genirq/affinity: Handle pre/post vectors in irq_calc_affinity_vectors()

Only calculate the affinity for the main I/O vectors, and skip the pre or
post vectors specified by struct irq_affinity.

Also remove the irq_affinity cpumask argument that has never been used.  If
we ever need it in the future we can pass it through struct irq_affinity.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Hannes Reinecke 
Acked-by: Jens Axboe 
Cc: linux-bl...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Link: http://lkml.kernel.org/r/1478654107-7384-3-git-send-email-...@lst.de
Signed-off-by: Thomas Gleixner 

---
 drivers/pci/msi.c |  8 
 include/linux/interrupt.h |  4 ++--
 kernel/irq/affinity.c | 24 ++--
 3 files changed, 16 insertions(+), 20 deletions(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index ad70507..dad2da7 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -1061,6 +1061,7 @@ EXPORT_SYMBOL(pci_msi_enabled);
 static int __pci_enable_msi_range(struct pci_dev *dev, int minvec, int maxvec,
unsigned int flags)
 {
+   static const struct irq_affinity default_affd;
bool affinity = flags & PCI_IRQ_AFFINITY;
int nvec;
int rc;
@@ -1091,8 +1092,7 @@ static int __pci_enable_msi_range(struct pci_dev *dev, 
int minvec, int maxvec,
 
for (;;) {
if (affinity) {
-   nvec = irq_calc_affinity_vectors(dev->irq_affinity,
-   nvec);
+   nvec = irq_calc_affinity_vectors(nvec, _affd);
if (nvec < minvec)
return -ENOSPC;
}
@@ -1132,6 +1132,7 @@ static int __pci_enable_msix_range(struct pci_dev *dev,
struct msix_entry *entries, int minvec, int maxvec,
unsigned int flags)
 {
+   static const struct irq_affinity default_affd;
bool affinity = flags & PCI_IRQ_AFFINITY;
int rc, nvec = maxvec;
 
@@ -1140,8 +1141,7 @@ static int __pci_enable_msix_range(struct pci_dev *dev,
 
for (;;) {
if (affinity) {
-   nvec = irq_calc_affinity_vectors(dev->irq_affinity,
-   nvec);
+   nvec = irq_calc_affinity_vectors(nvec, _affd);
if (nvec < minvec)
return -ENOSPC;
}
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 6b52686..9081f23 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -291,7 +291,7 @@ extern int
 irq_set_affinity_notifier(unsigned int irq, struct irq_affinity_notify 
*notify);
 
 struct cpumask *irq_create_affinity_masks(const struct cpumask *affinity, int 
nvec);
-int irq_calc_affinity_vectors(const struct cpumask *affinity, int maxvec);
+int irq_calc_affinity_vectors(int maxvec, const struct irq_affinity *affd);
 
 #else /* CONFIG_SMP */
 
@@ -331,7 +331,7 @@ irq_create_affinity_masks(const struct cpumask *affinity, 
int nvec)
 }
 
 static inline int
-irq_calc_affinity_vectors(const struct cpumask *affinity, int maxvec)
+irq_calc_affinity_vectors(int maxvec, const struct irq_affinity *affd)
 {
return maxvec;
 }
diff --git a/kernel/irq/affinity.c b/kernel/irq/affinity.c
index 17f51d63..8d92597 100644
--- a/kernel/irq/affinity.c
+++ b/kernel/irq/affinity.c
@@ -131,24 +131,20 @@ out:
 }
 
 /**
- * irq_calc_affinity_vectors - Calculate to optimal number of vectors for a 
given affinity mask
- * @affinity:  The affinity mask to spread. If NULL cpu_online_mask
- * is used
- * @maxvec:The maximum number of vectors available
+ * irq_calc_affinity_vectors - Calculate the optimal number of vectors
+ * @maxvec:The maximum number of vectors available
+ * @affd:  Description of the affinity requirements
  */
-int irq_calc_affinity_vectors(const struct cpumask *affinity, int maxvec)
+int irq_calc_affinity_vectors(int maxvec, const struct irq_affinity *affd)
 {
-   int cpus, ret;
+   int resv = affd->pre_vectors + affd->post_vectors;
+   int vecs = maxvec - resv;
+   int cpus;
 
/* Stabilize the cpumasks */
get_online_cpus();
-   /* If the supplied affinity mask is NULL, use cpu online mask */
-   if (!affinity)
-   affinity = cpu_online_mask;
-
-   cpus = cpumask_weight(affinity);
-   ret = (cpus < maxvec) ? cpus : maxvec;
-
+   cpus = cpumask_weight(cpu_online_mask);
put_online_cpus();
-   return ret;
+
+   return 

[tip:irq/core] genirq/affinity: Handle pre/post vectors in irq_calc_affinity_vectors()

[tip-bot for Christoph Hellwig]

Commit-ID:  212bd846223c718b6577d4df16fd8d05a55ad914
Gitweb: http://git.kernel.org/tip/212bd846223c718b6577d4df16fd8d05a55ad914
Author: Christoph Hellwig 
AuthorDate: Tue, 8 Nov 2016 17:15:02 -0800
Committer:  Thomas Gleixner 
CommitDate: Wed, 9 Nov 2016 08:25:08 +0100

genirq/affinity: Handle pre/post vectors in irq_calc_affinity_vectors()

Only calculate the affinity for the main I/O vectors, and skip the pre or
post vectors specified by struct irq_affinity.

Also remove the irq_affinity cpumask argument that has never been used.  If
we ever need it in the future we can pass it through struct irq_affinity.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Hannes Reinecke 
Acked-by: Jens Axboe 
Cc: linux-bl...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Link: http://lkml.kernel.org/r/1478654107-7384-3-git-send-email-...@lst.de
Signed-off-by: Thomas Gleixner 

---
 drivers/pci/msi.c |  8 
 include/linux/interrupt.h |  4 ++--
 kernel/irq/affinity.c | 24 ++--
 3 files changed, 16 insertions(+), 20 deletions(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index ad70507..dad2da7 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -1061,6 +1061,7 @@ EXPORT_SYMBOL(pci_msi_enabled);
 static int __pci_enable_msi_range(struct pci_dev *dev, int minvec, int maxvec,
unsigned int flags)
 {
+   static const struct irq_affinity default_affd;
bool affinity = flags & PCI_IRQ_AFFINITY;
int nvec;
int rc;
@@ -1091,8 +1092,7 @@ static int __pci_enable_msi_range(struct pci_dev *dev, 
int minvec, int maxvec,
 
for (;;) {
if (affinity) {
-   nvec = irq_calc_affinity_vectors(dev->irq_affinity,
-   nvec);
+   nvec = irq_calc_affinity_vectors(nvec, _affd);
if (nvec < minvec)
return -ENOSPC;
}
@@ -1132,6 +1132,7 @@ static int __pci_enable_msix_range(struct pci_dev *dev,
struct msix_entry *entries, int minvec, int maxvec,
unsigned int flags)
 {
+   static const struct irq_affinity default_affd;
bool affinity = flags & PCI_IRQ_AFFINITY;
int rc, nvec = maxvec;
 
@@ -1140,8 +1141,7 @@ static int __pci_enable_msix_range(struct pci_dev *dev,
 
for (;;) {
if (affinity) {
-   nvec = irq_calc_affinity_vectors(dev->irq_affinity,
-   nvec);
+   nvec = irq_calc_affinity_vectors(nvec, _affd);
if (nvec < minvec)
return -ENOSPC;
}
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 6b52686..9081f23 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -291,7 +291,7 @@ extern int
 irq_set_affinity_notifier(unsigned int irq, struct irq_affinity_notify 
*notify);
 
 struct cpumask *irq_create_affinity_masks(const struct cpumask *affinity, int 
nvec);
-int irq_calc_affinity_vectors(const struct cpumask *affinity, int maxvec);
+int irq_calc_affinity_vectors(int maxvec, const struct irq_affinity *affd);
 
 #else /* CONFIG_SMP */
 
@@ -331,7 +331,7 @@ irq_create_affinity_masks(const struct cpumask *affinity, 
int nvec)
 }
 
 static inline int
-irq_calc_affinity_vectors(const struct cpumask *affinity, int maxvec)
+irq_calc_affinity_vectors(int maxvec, const struct irq_affinity *affd)
 {
return maxvec;
 }
diff --git a/kernel/irq/affinity.c b/kernel/irq/affinity.c
index 17f51d63..8d92597 100644
--- a/kernel/irq/affinity.c
+++ b/kernel/irq/affinity.c
@@ -131,24 +131,20 @@ out:
 }
 
 /**
- * irq_calc_affinity_vectors - Calculate to optimal number of vectors for a 
given affinity mask
- * @affinity:  The affinity mask to spread. If NULL cpu_online_mask
- * is used
- * @maxvec:The maximum number of vectors available
+ * irq_calc_affinity_vectors - Calculate the optimal number of vectors
+ * @maxvec:The maximum number of vectors available
+ * @affd:  Description of the affinity requirements
  */
-int irq_calc_affinity_vectors(const struct cpumask *affinity, int maxvec)
+int irq_calc_affinity_vectors(int maxvec, const struct irq_affinity *affd)
 {
-   int cpus, ret;
+   int resv = affd->pre_vectors + affd->post_vectors;
+   int vecs = maxvec - resv;
+   int cpus;
 
/* Stabilize the cpumasks */
get_online_cpus();
-   /* If the supplied affinity mask is NULL, use cpu online mask */
-   if (!affinity)
-   affinity = cpu_online_mask;
-
-   cpus = cpumask_weight(affinity);
-   ret = (cpus < maxvec) ? cpus : maxvec;
-
+   cpus = cpumask_weight(cpu_online_mask);
put_online_cpus();
-   return ret;
+
+   return min(cpus, vecs) + resv;
 }

[tip:irq/core] genirq/affinity: Introduce struct irq_affinity

[tip-bot for Christoph Hellwig]

Commit-ID:  20e407e195b29a4f5a18d713a61f54a75f992bd5
Gitweb: http://git.kernel.org/tip/20e407e195b29a4f5a18d713a61f54a75f992bd5
Author: Christoph Hellwig 
AuthorDate: Tue, 8 Nov 2016 17:15:01 -0800
Committer:  Thomas Gleixner 
CommitDate: Wed, 9 Nov 2016 08:25:08 +0100

genirq/affinity: Introduce struct irq_affinity

Some drivers (various network and RDMA adapter for example) have a MSI-X
vector layout where most of the vectors are used for I/O queues and should
have CPU affinity assigned to them, but some (usually 1 but sometimes more)
at the beginning or end are used for low-performance admin or configuration
work and should not have any explicit affinity assigned to them.

Add a new irq_affinity structure, which will be passed through a variant of
pci_irq_alloc_vectors that allows to specify these requirements (and is
extensible to any future quirks in that area) so that the core IRQ affinity
algorithm can take this quirks into account.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Johannes Thumshirn 
Reviewed-by: Hannes Reinecke 
Acked-by: Jens Axboe 
Cc: linux-bl...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Link: http://lkml.kernel.org/r/1478654107-7384-2-git-send-email-...@lst.de
Signed-off-by: Thomas Gleixner 

---
 include/linux/interrupt.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 72f0721..6b52686 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -232,6 +232,18 @@ struct irq_affinity_notify {
void (*release)(struct kref *ref);
 };
 
+/**
+ * struct irq_affinity - Description for automatic irq affinity assignements
+ * @pre_vectors:   Don't apply affinity to @pre_vectors at beginning of
+ * the MSI(-X) vector space
+ * @post_vectors:  Don't apply affinity to @post_vectors at end of
+ * the MSI(-X) vector space
+ */
+struct irq_affinity {
+   int pre_vectors;
+   int post_vectors;
+};
+
 #if defined(CONFIG_SMP)
 
 extern cpumask_var_t irq_default_affinity;

[tip:irq/core] genirq/affinity: Introduce struct irq_affinity

[tip-bot for Christoph Hellwig]

Commit-ID:  20e407e195b29a4f5a18d713a61f54a75f992bd5
Gitweb: http://git.kernel.org/tip/20e407e195b29a4f5a18d713a61f54a75f992bd5
Author: Christoph Hellwig 
AuthorDate: Tue, 8 Nov 2016 17:15:01 -0800
Committer:  Thomas Gleixner 
CommitDate: Wed, 9 Nov 2016 08:25:08 +0100

genirq/affinity: Introduce struct irq_affinity

Some drivers (various network and RDMA adapter for example) have a MSI-X
vector layout where most of the vectors are used for I/O queues and should
have CPU affinity assigned to them, but some (usually 1 but sometimes more)
at the beginning or end are used for low-performance admin or configuration
work and should not have any explicit affinity assigned to them.

Add a new irq_affinity structure, which will be passed through a variant of
pci_irq_alloc_vectors that allows to specify these requirements (and is
extensible to any future quirks in that area) so that the core IRQ affinity
algorithm can take this quirks into account.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Johannes Thumshirn 
Reviewed-by: Hannes Reinecke 
Acked-by: Jens Axboe 
Cc: linux-bl...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Link: http://lkml.kernel.org/r/1478654107-7384-2-git-send-email-...@lst.de
Signed-off-by: Thomas Gleixner 

---
 include/linux/interrupt.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 72f0721..6b52686 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -232,6 +232,18 @@ struct irq_affinity_notify {
void (*release)(struct kref *ref);
 };
 
+/**
+ * struct irq_affinity - Description for automatic irq affinity assignements
+ * @pre_vectors:   Don't apply affinity to @pre_vectors at beginning of
+ * the MSI(-X) vector space
+ * @post_vectors:  Don't apply affinity to @post_vectors at end of
+ * the MSI(-X) vector space
+ */
+struct irq_affinity {
+   int pre_vectors;
+   int post_vectors;
+};
+
 #if defined(CONFIG_SMP)
 
 extern cpumask_var_t irq_default_affinity;

Re: Summary of LPC guest MSI discussion in Santa Fe

[Auger Eric]

Hi Will,
On 08/11/2016 20:02, Don Dutile wrote:
> On 11/08/2016 12:54 PM, Will Deacon wrote:
>> On Tue, Nov 08, 2016 at 03:27:23PM +0100, Auger Eric wrote:
>>> On 08/11/2016 03:45, Will Deacon wrote:
 Rather than treat these as separate problems, a better interface is to
 tell userspace about a set of reserved regions, and have this include
 the MSI doorbell, irrespective of whether or not it can be remapped.
 Don suggested that we statically pick an address for the doorbell in a
 similar way to x86, and have the kernel map it there. We could even
 pick
 0xfee0. If it conflicts with a reserved region on the platform (due
 to (4)), then we'd obviously have to (deterministically?) allocate it
 somewhere else, but probably within the bottom 4G.
>>> This is tentatively achieved now with
>>> [1] [RFC v2 0/8] KVM PCIe/MSI passthrough on ARM/ARM64 - Alt II
>>> (http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1264506.html)
>>>
>> Yup, I saw that fly by. Hopefully some of the internals can be reused
>> with the current thinking on user ABI.
>>
 The next question is how to tell userspace about all of the reserved
 regions. Initially, the idea was to extend VFIO, however Alex pointed
 out a horrible scenario:

1. QEMU spawns a VM on system 0
2. VM is migrated to system 1
3. QEMU attempts to passthrough a device using PCI hotplug

 In this scenario, the guest memory map is chosen at step (1), yet there
 is no VFIO fd available to determine the reserved regions. Furthermore,
 the reserved regions may vary between system 0 and system 1. This
 pretty
 much rules out using VFIO to determine the reserved regions.Alex
 suggested
 that the SMMU driver can advertise the regions via
 /sys/class/iommu/. This
 would solve part of the problem, but migration between systems with
 different memory maps can still cause problems if the reserved regions
 of the new system conflict with the guest memory map chosen by QEMU.
>>>
>>> OK so I understand we do not want anymore the VFIO chain capability API
>>> (patch 5 of above series) but we prefer a sysfs approach instead.
>> Right.
>>
>>> I understand the sysfs approach which allows the userspace to get the
>>> info earlier and independently on VFIO. Keeping in mind current QEMU
>>> virt - which is not the only userspace - will not do much from this info
>>> until we bring upheavals in virt address space management. So if I am
>>> not wrong, at the moment the main action to be undertaken is the
>>> rejection of the PCI hotplug in case we detect a collision.
>> I don't think so; it should be up to userspace to reject the hotplug.
>> If userspace doesn't have support for the regions, then that's fine --
>> you just end up in a situation where the CPU page table maps memory
>> somewhere that the device can't see. In other words, you'll end up with
>> spurious DMA failures, but that's exactly what happens with current
>> systems
>> if you passthrough an overlapping region (Robin demonstrated this on
>> Juno).
>>
>> Additionally, you can imagine some future support where you can tell the
>> guest not to use certain regions of its memory for DMA. In this case, you
>> wouldn't want to refuse the hotplug in the case of overlapping regions.
>>
>> Really, I think the kernel side just needs to enumerate the fixed
>> reserved
>> regions, place the doorbell at a fixed address and then advertise these
>> via sysfs.
>>
>>> I can respin [1]
>>> - studying and taking into account Robin's comments about dm_regions
>>> similarities
>>> - removing the VFIO capability chain and replacing this by a sysfs API
>> Ideally, this would be reusable between different SMMU drivers so the
>> sysfs
>> entries have the same format etc.
>>
>>> Would that be OK?
>> Sounds good to me. Are you in a position to prototype something on the
>> qemu
>> side once we've got kernel-side agreement?
yes sure.
>>
>>> What about Alex comments who wanted to report the usable memory ranges
>>> instead of unusable memory ranges?
>>>
>>> Also did you have a chance to discuss the following items:
>>> 1) the VFIO irq safety assessment
>> The discussion really focussed on system topology, as opposed to
>> properties
>> of the doorbell. Regardless of how the device talks to the doorbell, if
>> the doorbell can't protect against things like MSI spoofing, then it's
>> unsafe. My opinion is that we shouldn't allow passthrough by default on
>> systems with unsafe doorbells (we could piggyback on
>> allow_unsafe_interrupts
>> cmdline option to VFIO).
OK.
>>
>> A first step would be making all this opt-in, and only supporting GICv3
>> ITS for now.
> You're trying to support a config that is < GICv3 and no ITS ? ...
> That would be the equiv. of x86 pre-intr-remap, and that's why
> allow_unsafe_interrupts
> hook was created ... to enable devel/kick-the-tires.
>>> 2) the MSI reserved size computation (is an 

Re: Summary of LPC guest MSI discussion in Santa Fe

[Auger Eric]

Hi Will,
On 08/11/2016 20:02, Don Dutile wrote:
> On 11/08/2016 12:54 PM, Will Deacon wrote:
>> On Tue, Nov 08, 2016 at 03:27:23PM +0100, Auger Eric wrote:
>>> On 08/11/2016 03:45, Will Deacon wrote:
 Rather than treat these as separate problems, a better interface is to
 tell userspace about a set of reserved regions, and have this include
 the MSI doorbell, irrespective of whether or not it can be remapped.
 Don suggested that we statically pick an address for the doorbell in a
 similar way to x86, and have the kernel map it there. We could even
 pick
 0xfee0. If it conflicts with a reserved region on the platform (due
 to (4)), then we'd obviously have to (deterministically?) allocate it
 somewhere else, but probably within the bottom 4G.
>>> This is tentatively achieved now with
>>> [1] [RFC v2 0/8] KVM PCIe/MSI passthrough on ARM/ARM64 - Alt II
>>> (http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1264506.html)
>>>
>> Yup, I saw that fly by. Hopefully some of the internals can be reused
>> with the current thinking on user ABI.
>>
 The next question is how to tell userspace about all of the reserved
 regions. Initially, the idea was to extend VFIO, however Alex pointed
 out a horrible scenario:

1. QEMU spawns a VM on system 0
2. VM is migrated to system 1
3. QEMU attempts to passthrough a device using PCI hotplug

 In this scenario, the guest memory map is chosen at step (1), yet there
 is no VFIO fd available to determine the reserved regions. Furthermore,
 the reserved regions may vary between system 0 and system 1. This
 pretty
 much rules out using VFIO to determine the reserved regions.Alex
 suggested
 that the SMMU driver can advertise the regions via
 /sys/class/iommu/. This
 would solve part of the problem, but migration between systems with
 different memory maps can still cause problems if the reserved regions
 of the new system conflict with the guest memory map chosen by QEMU.
>>>
>>> OK so I understand we do not want anymore the VFIO chain capability API
>>> (patch 5 of above series) but we prefer a sysfs approach instead.
>> Right.
>>
>>> I understand the sysfs approach which allows the userspace to get the
>>> info earlier and independently on VFIO. Keeping in mind current QEMU
>>> virt - which is not the only userspace - will not do much from this info
>>> until we bring upheavals in virt address space management. So if I am
>>> not wrong, at the moment the main action to be undertaken is the
>>> rejection of the PCI hotplug in case we detect a collision.
>> I don't think so; it should be up to userspace to reject the hotplug.
>> If userspace doesn't have support for the regions, then that's fine --
>> you just end up in a situation where the CPU page table maps memory
>> somewhere that the device can't see. In other words, you'll end up with
>> spurious DMA failures, but that's exactly what happens with current
>> systems
>> if you passthrough an overlapping region (Robin demonstrated this on
>> Juno).
>>
>> Additionally, you can imagine some future support where you can tell the
>> guest not to use certain regions of its memory for DMA. In this case, you
>> wouldn't want to refuse the hotplug in the case of overlapping regions.
>>
>> Really, I think the kernel side just needs to enumerate the fixed
>> reserved
>> regions, place the doorbell at a fixed address and then advertise these
>> via sysfs.
>>
>>> I can respin [1]
>>> - studying and taking into account Robin's comments about dm_regions
>>> similarities
>>> - removing the VFIO capability chain and replacing this by a sysfs API
>> Ideally, this would be reusable between different SMMU drivers so the
>> sysfs
>> entries have the same format etc.
>>
>>> Would that be OK?
>> Sounds good to me. Are you in a position to prototype something on the
>> qemu
>> side once we've got kernel-side agreement?
yes sure.
>>
>>> What about Alex comments who wanted to report the usable memory ranges
>>> instead of unusable memory ranges?
>>>
>>> Also did you have a chance to discuss the following items:
>>> 1) the VFIO irq safety assessment
>> The discussion really focussed on system topology, as opposed to
>> properties
>> of the doorbell. Regardless of how the device talks to the doorbell, if
>> the doorbell can't protect against things like MSI spoofing, then it's
>> unsafe. My opinion is that we shouldn't allow passthrough by default on
>> systems with unsafe doorbells (we could piggyback on
>> allow_unsafe_interrupts
>> cmdline option to VFIO).
OK.
>>
>> A first step would be making all this opt-in, and only supporting GICv3
>> ITS for now.
> You're trying to support a config that is < GICv3 and no ITS ? ...
> That would be the equiv. of x86 pre-intr-remap, and that's why
> allow_unsafe_interrupts
> hook was created ... to enable devel/kick-the-tires.
>>> 2) the MSI reserved size computation (is an 

Re: [PATCH 1/6] mm: khugepaged: fix radix tree node leak in shmem collapse error path

[Jan Kara]

On Tue 08-11-16 11:12:45, Johannes Weiner wrote:
> On Tue, Nov 08, 2016 at 10:53:52AM +0100, Jan Kara wrote:
> > On Mon 07-11-16 14:07:36, Johannes Weiner wrote:
> > > The radix tree counts valid entries in each tree node. Entries stored
> > > in the tree cannot be removed by simpling storing NULL in the slot or
> > > the internal counters will be off and the node never gets freed again.
> > > 
> > > When collapsing a shmem page fails, restore the holes that were filled
> > > with radix_tree_insert() with a proper radix tree deletion.
> > > 
> > > Fixes: f3f0e1d2150b ("khugepaged: add support of collapse for tmpfs/shmem 
> > > pages")
> > > Reported-by: Jan Kara 
> > > Signed-off-by: Johannes Weiner 
> > > ---
> > >  mm/khugepaged.c | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> > > index 728d7790dc2d..eac6f0580e26 100644
> > > --- a/mm/khugepaged.c
> > > +++ b/mm/khugepaged.c
> > > @@ -1520,7 +1520,8 @@ static void collapse_shmem(struct mm_struct *mm,
> > >   if (!nr_none)
> > >   break;
> > >   /* Put holes back where they were */
> > > - radix_tree_replace_slot(slot, NULL);
> > > + radix_tree_delete(>page_tree,
> > > +   iter.index);
> > 
> > Hum, but this is inside radix_tree_for_each_slot() iteration. And
> > radix_tree_delete() may end up freeing nodes resulting in invalidating
> > current slot pointer and the iteration code will do use-after-free.
> 
> Good point, we need to do another tree lookup after the deletion.
> 
> But there are other instances in the code, where we drop the lock
> temporarily and somebody else could delete the node from under us.
> 
> In the main collapse path, I *think* this is prevented by the fact
> that when we drop the tree lock we still hold the page lock of the
> regular page that's in the tree while we isolate and unmap it, thus
> pin the node. Even so, it would seem a little hairy to rely on that.

Yeah, I think that is mostly right but I'm not sure whether shrinking of
radix tree into direct pointer cannot bite us here as well. Generally that
relies on internal implementatation of the radix tree and its iterator
so what you did makes sense to me.

Honza
-- 
Jan Kara 
SUSE Labs, CR

Re: [PATCH 1/6] mm: khugepaged: fix radix tree node leak in shmem collapse error path

[Jan Kara]

On Tue 08-11-16 11:12:45, Johannes Weiner wrote:
> On Tue, Nov 08, 2016 at 10:53:52AM +0100, Jan Kara wrote:
> > On Mon 07-11-16 14:07:36, Johannes Weiner wrote:
> > > The radix tree counts valid entries in each tree node. Entries stored
> > > in the tree cannot be removed by simpling storing NULL in the slot or
> > > the internal counters will be off and the node never gets freed again.
> > > 
> > > When collapsing a shmem page fails, restore the holes that were filled
> > > with radix_tree_insert() with a proper radix tree deletion.
> > > 
> > > Fixes: f3f0e1d2150b ("khugepaged: add support of collapse for tmpfs/shmem 
> > > pages")
> > > Reported-by: Jan Kara 
> > > Signed-off-by: Johannes Weiner 
> > > ---
> > >  mm/khugepaged.c | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> > > index 728d7790dc2d..eac6f0580e26 100644
> > > --- a/mm/khugepaged.c
> > > +++ b/mm/khugepaged.c
> > > @@ -1520,7 +1520,8 @@ static void collapse_shmem(struct mm_struct *mm,
> > >   if (!nr_none)
> > >   break;
> > >   /* Put holes back where they were */
> > > - radix_tree_replace_slot(slot, NULL);
> > > + radix_tree_delete(>page_tree,
> > > +   iter.index);
> > 
> > Hum, but this is inside radix_tree_for_each_slot() iteration. And
> > radix_tree_delete() may end up freeing nodes resulting in invalidating
> > current slot pointer and the iteration code will do use-after-free.
> 
> Good point, we need to do another tree lookup after the deletion.
> 
> But there are other instances in the code, where we drop the lock
> temporarily and somebody else could delete the node from under us.
> 
> In the main collapse path, I *think* this is prevented by the fact
> that when we drop the tree lock we still hold the page lock of the
> regular page that's in the tree while we isolate and unmap it, thus
> pin the node. Even so, it would seem a little hairy to rely on that.

Yeah, I think that is mostly right but I'm not sure whether shrinking of
radix tree into direct pointer cannot bite us here as well. Generally that
relies on internal implementatation of the radix tree and its iterator
so what you did makes sense to me.

Honza
-- 
Jan Kara 
SUSE Labs, CR

[PATCH 3/3] vhost_net: tx support batching

[Jason Wang]

This patch tries to utilize tuntap rx batching by peeking the tx
virtqueue during transmission, if there's more available buffers in
the virtqueue, set MSG_MORE flag for a hint for tuntap to batch the
packets. The maximum number of batched tx packets were specified
through a module parameter: tx_bached.

When use 16 as tx_batched:

Pktgen test shows 16% on tx pps in guest.
Netperf test does not show obvious regression.

For safety, 1 were used as the default value for tx_batched.

Signed-off-by: Jason Wang 
---
 drivers/vhost/net.c   | 15 ++-
 drivers/vhost/vhost.c |  1 +
 drivers/vhost/vhost.h |  1 +
 3 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 5dc128a..51c378e 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -35,6 +35,10 @@ module_param(experimental_zcopytx, int, 0444);
 MODULE_PARM_DESC(experimental_zcopytx, "Enable Zero Copy TX;"
   " 1 -Enable; 0 - Disable");
 
+static int tx_batched = 1;
+module_param(tx_batched, int, 0444);
+MODULE_PARM_DESC(tx_batched, "Number of patches batched in TX");
+
 /* Max number of bytes transferred before requeueing the job.
  * Using this limit prevents one virtqueue from starving others. */
 #define VHOST_NET_WEIGHT 0x8
@@ -454,6 +458,16 @@ static void handle_tx(struct vhost_net *net)
msg.msg_control = NULL;
ubufs = NULL;
}
+   total_len += len;
+   if (vq->delayed < tx_batched &&
+   total_len < VHOST_NET_WEIGHT &&
+   !vhost_vq_avail_empty(>dev, vq)) {
+   vq->delayed++;
+   msg.msg_flags |= MSG_MORE;
+   } else {
+   vq->delayed = 0;
+   msg.msg_flags &= ~MSG_MORE;
+   }
/* TODO: Check specific error and bomb out unless ENOBUFS? */
err = sock->ops->sendmsg(sock, , len);
if (unlikely(err < 0)) {
@@ -472,7 +486,6 @@ static void handle_tx(struct vhost_net *net)
vhost_add_used_and_signal(>dev, vq, head, 0);
else
vhost_zerocopy_signal_used(net, vq);
-   total_len += len;
vhost_net_tx_packet(net);
if (unlikely(total_len >= VHOST_NET_WEIGHT)) {
vhost_poll_queue(>poll);
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index fdf4cdf..bc362c7 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -311,6 +311,7 @@ static void vhost_vq_reset(struct vhost_dev *dev,
vq->busyloop_timeout = 0;
vq->umem = NULL;
vq->iotlb = NULL;
+   vq->delayed = 0;
 }
 
 static int vhost_worker(void *data)
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index 78f3c5f..9f81a94 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -141,6 +141,7 @@ struct vhost_virtqueue {
bool user_be;
 #endif
u32 busyloop_timeout;
+   int delayed;
 };
 
 struct vhost_msg_node {
-- 
2.7.4

[PATCH 3/3] vhost_net: tx support batching

[Jason Wang]

This patch tries to utilize tuntap rx batching by peeking the tx
virtqueue during transmission, if there's more available buffers in
the virtqueue, set MSG_MORE flag for a hint for tuntap to batch the
packets. The maximum number of batched tx packets were specified
through a module parameter: tx_bached.

When use 16 as tx_batched:

Pktgen test shows 16% on tx pps in guest.
Netperf test does not show obvious regression.

For safety, 1 were used as the default value for tx_batched.

Signed-off-by: Jason Wang 
---
 drivers/vhost/net.c   | 15 ++-
 drivers/vhost/vhost.c |  1 +
 drivers/vhost/vhost.h |  1 +
 3 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 5dc128a..51c378e 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -35,6 +35,10 @@ module_param(experimental_zcopytx, int, 0444);
 MODULE_PARM_DESC(experimental_zcopytx, "Enable Zero Copy TX;"
   " 1 -Enable; 0 - Disable");
 
+static int tx_batched = 1;
+module_param(tx_batched, int, 0444);
+MODULE_PARM_DESC(tx_batched, "Number of patches batched in TX");
+
 /* Max number of bytes transferred before requeueing the job.
  * Using this limit prevents one virtqueue from starving others. */
 #define VHOST_NET_WEIGHT 0x8
@@ -454,6 +458,16 @@ static void handle_tx(struct vhost_net *net)
msg.msg_control = NULL;
ubufs = NULL;
}
+   total_len += len;
+   if (vq->delayed < tx_batched &&
+   total_len < VHOST_NET_WEIGHT &&
+   !vhost_vq_avail_empty(>dev, vq)) {
+   vq->delayed++;
+   msg.msg_flags |= MSG_MORE;
+   } else {
+   vq->delayed = 0;
+   msg.msg_flags &= ~MSG_MORE;
+   }
/* TODO: Check specific error and bomb out unless ENOBUFS? */
err = sock->ops->sendmsg(sock, , len);
if (unlikely(err < 0)) {
@@ -472,7 +486,6 @@ static void handle_tx(struct vhost_net *net)
vhost_add_used_and_signal(>dev, vq, head, 0);
else
vhost_zerocopy_signal_used(net, vq);
-   total_len += len;
vhost_net_tx_packet(net);
if (unlikely(total_len >= VHOST_NET_WEIGHT)) {
vhost_poll_queue(>poll);
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index fdf4cdf..bc362c7 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -311,6 +311,7 @@ static void vhost_vq_reset(struct vhost_dev *dev,
vq->busyloop_timeout = 0;
vq->umem = NULL;
vq->iotlb = NULL;
+   vq->delayed = 0;
 }
 
 static int vhost_worker(void *data)
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index 78f3c5f..9f81a94 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -141,6 +141,7 @@ struct vhost_virtqueue {
bool user_be;
 #endif
u32 busyloop_timeout;
+   int delayed;
 };
 
 struct vhost_msg_node {
-- 
2.7.4

[PATCH 2/3] vhost: better detection of available buffers

[Jason Wang]

We should use vq->last_avail_idx instead of vq->avail_idx in the
checking of vhost_vq_avail_empty() since latter is the cached avail
index from guest but we want to know if there's pending available
buffers in the virtqueue.

Signed-off-by: Jason Wang 
---
 drivers/vhost/vhost.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index c6f2d89..fdf4cdf 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -2230,7 +2230,7 @@ bool vhost_vq_avail_empty(struct vhost_dev *dev, struct 
vhost_virtqueue *vq)
if (r)
return false;
 
-   return vhost16_to_cpu(vq, avail_idx) == vq->avail_idx;
+   return vhost16_to_cpu(vq, avail_idx) == vq->last_avail_idx;
 }
 EXPORT_SYMBOL_GPL(vhost_vq_avail_empty);
 
-- 
2.7.4

[PATCH 1/3] tuntap: rx batching

[Jason Wang]

Backlog were used for tuntap rx, but it can only process 1 packet at
one time since it was scheduled during sendmsg() synchronously in
process context. This lead bad cache utilization so this patch tries
to do some batching before call rx NAPI. This is done through:

- accept MSG_MORE as a hint from sendmsg() caller, if it was set,
  batch the packet temporarily in a linked list and submit them all
  once MSG_MORE were cleared.
- implement a tuntap specific NAPI handler for processing this kind of
  possible batching. (This could be done by extending backlog to
  support skb like, but using a tun specific one looks cleaner and
  easier for future extension).

Signed-off-by: Jason Wang 
---
 drivers/net/tun.c | 71 ++-
 1 file changed, 65 insertions(+), 6 deletions(-)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 1588469..d40583b 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -74,6 +74,7 @@
 #include 
 
 #include 
+#include 
 
 /* Uncomment to enable debugging */
 /* #define TUN_DEBUG 1 */
@@ -169,6 +170,8 @@ struct tun_file {
struct list_head next;
struct tun_struct *detached;
struct skb_array tx_array;
+   struct napi_struct napi;
+   struct sk_buff_head process_queue;
 };
 
 struct tun_flow_entry {
@@ -522,6 +525,8 @@ static void tun_queue_purge(struct tun_file *tfile)
while ((skb = skb_array_consume(>tx_array)) != NULL)
kfree_skb(skb);
 
+   skb_queue_purge(>sk.sk_write_queue);
+   skb_queue_purge(>process_queue);
skb_queue_purge(>sk.sk_error_queue);
 }
 
@@ -532,6 +537,11 @@ static void __tun_detach(struct tun_file *tfile, bool 
clean)
 
tun = rtnl_dereference(tfile->tun);
 
+   if (tun && clean) {
+   napi_disable(>napi);
+   netif_napi_del(>napi);
+   }
+
if (tun && !tfile->detached) {
u16 index = tfile->queue_index;
BUG_ON(index >= tun->numqueues);
@@ -587,6 +597,7 @@ static void tun_detach_all(struct net_device *dev)
 
for (i = 0; i < n; i++) {
tfile = rtnl_dereference(tun->tfiles[i]);
+   napi_disable(>napi);
BUG_ON(!tfile);
tfile->socket.sk->sk_shutdown = RCV_SHUTDOWN;
tfile->socket.sk->sk_data_ready(tfile->socket.sk);
@@ -603,6 +614,7 @@ static void tun_detach_all(struct net_device *dev)
synchronize_net();
for (i = 0; i < n; i++) {
tfile = rtnl_dereference(tun->tfiles[i]);
+   netif_napi_del(>napi);
/* Drop read queue */
tun_queue_purge(tfile);
sock_put(>sk);
@@ -618,6 +630,41 @@ static void tun_detach_all(struct net_device *dev)
module_put(THIS_MODULE);
 }
 
+static int tun_poll(struct napi_struct *napi, int budget)
+{
+   struct tun_file *tfile = container_of(napi, struct tun_file, napi);
+   struct sk_buff_head *input_queue =
+  >socket.sk->sk_write_queue;
+   struct sk_buff *skb;
+   unsigned int received = 0;
+
+   while (1) {
+   while ((skb = __skb_dequeue(>process_queue))) {
+   netif_receive_skb(skb);
+   if (++received >= budget)
+   return received;
+   }
+
+   spin_lock(_queue->lock);
+   if (skb_queue_empty(input_queue)) {
+   spin_unlock(_queue->lock);
+   break;
+   }
+   skb_queue_splice_tail_init(input_queue, >process_queue);
+   spin_unlock(_queue->lock);
+   }
+
+   if (received < budget) {
+   napi_complete(napi);
+   if (skb_peek(>socket.sk->sk_write_queue) &&
+   unlikely(napi_schedule_prep(napi))) {
+   __napi_schedule(napi);
+   }
+   }
+
+   return received;
+}
+
 static int tun_attach(struct tun_struct *tun, struct file *file, bool 
skip_filter)
 {
struct tun_file *tfile = file->private_data;
@@ -666,9 +713,11 @@ static int tun_attach(struct tun_struct *tun, struct file 
*file, bool skip_filte
 
if (tfile->detached)
tun_enable_queue(tfile);
-   else
+   else {
sock_hold(>sk);
-
+   netif_napi_add(tun->dev, >napi, tun_poll, 64);
+   napi_enable(>napi);
+   }
tun_set_real_num_queues(tun);
 
/* device is allowed to go away first, so no need to hold extra
@@ -1150,7 +1199,7 @@ static struct sk_buff *tun_alloc_skb(struct tun_file 
*tfile,
 /* Get packet from user space buffer */
 static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
void *msg_control, struct iov_iter *from,
-   int noblock)
+   int noblock, bool more)
 {
struct tun_pi 

[PATCH 2/3] vhost: better detection of available buffers

[Jason Wang]

We should use vq->last_avail_idx instead of vq->avail_idx in the
checking of vhost_vq_avail_empty() since latter is the cached avail
index from guest but we want to know if there's pending available
buffers in the virtqueue.

Signed-off-by: Jason Wang 
---
 drivers/vhost/vhost.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index c6f2d89..fdf4cdf 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -2230,7 +2230,7 @@ bool vhost_vq_avail_empty(struct vhost_dev *dev, struct 
vhost_virtqueue *vq)
if (r)
return false;
 
-   return vhost16_to_cpu(vq, avail_idx) == vq->avail_idx;
+   return vhost16_to_cpu(vq, avail_idx) == vq->last_avail_idx;
 }
 EXPORT_SYMBOL_GPL(vhost_vq_avail_empty);
 
-- 
2.7.4

[PATCH 1/3] tuntap: rx batching

[Jason Wang]

Backlog were used for tuntap rx, but it can only process 1 packet at
one time since it was scheduled during sendmsg() synchronously in
process context. This lead bad cache utilization so this patch tries
to do some batching before call rx NAPI. This is done through:

- accept MSG_MORE as a hint from sendmsg() caller, if it was set,
  batch the packet temporarily in a linked list and submit them all
  once MSG_MORE were cleared.
- implement a tuntap specific NAPI handler for processing this kind of
  possible batching. (This could be done by extending backlog to
  support skb like, but using a tun specific one looks cleaner and
  easier for future extension).

Signed-off-by: Jason Wang 
---
 drivers/net/tun.c | 71 ++-
 1 file changed, 65 insertions(+), 6 deletions(-)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 1588469..d40583b 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -74,6 +74,7 @@
 #include 
 
 #include 
+#include 
 
 /* Uncomment to enable debugging */
 /* #define TUN_DEBUG 1 */
@@ -169,6 +170,8 @@ struct tun_file {
struct list_head next;
struct tun_struct *detached;
struct skb_array tx_array;
+   struct napi_struct napi;
+   struct sk_buff_head process_queue;
 };
 
 struct tun_flow_entry {
@@ -522,6 +525,8 @@ static void tun_queue_purge(struct tun_file *tfile)
while ((skb = skb_array_consume(>tx_array)) != NULL)
kfree_skb(skb);
 
+   skb_queue_purge(>sk.sk_write_queue);
+   skb_queue_purge(>process_queue);
skb_queue_purge(>sk.sk_error_queue);
 }
 
@@ -532,6 +537,11 @@ static void __tun_detach(struct tun_file *tfile, bool 
clean)
 
tun = rtnl_dereference(tfile->tun);
 
+   if (tun && clean) {
+   napi_disable(>napi);
+   netif_napi_del(>napi);
+   }
+
if (tun && !tfile->detached) {
u16 index = tfile->queue_index;
BUG_ON(index >= tun->numqueues);
@@ -587,6 +597,7 @@ static void tun_detach_all(struct net_device *dev)
 
for (i = 0; i < n; i++) {
tfile = rtnl_dereference(tun->tfiles[i]);
+   napi_disable(>napi);
BUG_ON(!tfile);
tfile->socket.sk->sk_shutdown = RCV_SHUTDOWN;
tfile->socket.sk->sk_data_ready(tfile->socket.sk);
@@ -603,6 +614,7 @@ static void tun_detach_all(struct net_device *dev)
synchronize_net();
for (i = 0; i < n; i++) {
tfile = rtnl_dereference(tun->tfiles[i]);
+   netif_napi_del(>napi);
/* Drop read queue */
tun_queue_purge(tfile);
sock_put(>sk);
@@ -618,6 +630,41 @@ static void tun_detach_all(struct net_device *dev)
module_put(THIS_MODULE);
 }
 
+static int tun_poll(struct napi_struct *napi, int budget)
+{
+   struct tun_file *tfile = container_of(napi, struct tun_file, napi);
+   struct sk_buff_head *input_queue =
+  >socket.sk->sk_write_queue;
+   struct sk_buff *skb;
+   unsigned int received = 0;
+
+   while (1) {
+   while ((skb = __skb_dequeue(>process_queue))) {
+   netif_receive_skb(skb);
+   if (++received >= budget)
+   return received;
+   }
+
+   spin_lock(_queue->lock);
+   if (skb_queue_empty(input_queue)) {
+   spin_unlock(_queue->lock);
+   break;
+   }
+   skb_queue_splice_tail_init(input_queue, >process_queue);
+   spin_unlock(_queue->lock);
+   }
+
+   if (received < budget) {
+   napi_complete(napi);
+   if (skb_peek(>socket.sk->sk_write_queue) &&
+   unlikely(napi_schedule_prep(napi))) {
+   __napi_schedule(napi);
+   }
+   }
+
+   return received;
+}
+
 static int tun_attach(struct tun_struct *tun, struct file *file, bool 
skip_filter)
 {
struct tun_file *tfile = file->private_data;
@@ -666,9 +713,11 @@ static int tun_attach(struct tun_struct *tun, struct file 
*file, bool skip_filte
 
if (tfile->detached)
tun_enable_queue(tfile);
-   else
+   else {
sock_hold(>sk);
-
+   netif_napi_add(tun->dev, >napi, tun_poll, 64);
+   napi_enable(>napi);
+   }
tun_set_real_num_queues(tun);
 
/* device is allowed to go away first, so no need to hold extra
@@ -1150,7 +1199,7 @@ static struct sk_buff *tun_alloc_skb(struct tun_file 
*tfile,
 /* Get packet from user space buffer */
 static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
void *msg_control, struct iov_iter *from,
-   int noblock)
+   int noblock, bool more)
 {
struct tun_pi pi = { 0, 

[PATCH] net/mlx4_en: Fix bpf_prog_add ref_cnt in mlx4

[Zhiyi Sun]

There are rx_ring_num queues. Each queue will load xdp prog. So
bpf_prog_add() should add rx_ring_num to ref_cnt.

Signed-off-by: Zhiyi Sun 
---
 drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c 
b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index 12c99a2..d25e150 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -2650,7 +2650,7 @@ static int mlx4_xdp_set(struct net_device *dev, struct 
bpf_prog *prog)
 */
if (priv->xdp_ring_num == xdp_ring_num) {
if (prog) {
-   prog = bpf_prog_add(prog, priv->rx_ring_num - 1);
+   prog = bpf_prog_add(prog, priv->rx_ring_num);
if (IS_ERR(prog))
return PTR_ERR(prog);
}
@@ -2680,7 +2680,7 @@ static int mlx4_xdp_set(struct net_device *dev, struct 
bpf_prog *prog)
}
 
if (prog) {
-   prog = bpf_prog_add(prog, priv->rx_ring_num - 1);
+   prog = bpf_prog_add(prog, priv->rx_ring_num);
if (IS_ERR(prog))
return PTR_ERR(prog);
}
-- 
2.9.3

[PATCH] net/mlx4_en: Fix bpf_prog_add ref_cnt in mlx4

[Zhiyi Sun]

There are rx_ring_num queues. Each queue will load xdp prog. So
bpf_prog_add() should add rx_ring_num to ref_cnt.

Signed-off-by: Zhiyi Sun 
---
 drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c 
b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index 12c99a2..d25e150 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -2650,7 +2650,7 @@ static int mlx4_xdp_set(struct net_device *dev, struct 
bpf_prog *prog)
 */
if (priv->xdp_ring_num == xdp_ring_num) {
if (prog) {
-   prog = bpf_prog_add(prog, priv->rx_ring_num - 1);
+   prog = bpf_prog_add(prog, priv->rx_ring_num);
if (IS_ERR(prog))
return PTR_ERR(prog);
}
@@ -2680,7 +2680,7 @@ static int mlx4_xdp_set(struct net_device *dev, struct 
bpf_prog *prog)
}
 
if (prog) {
-   prog = bpf_prog_add(prog, priv->rx_ring_num - 1);
+   prog = bpf_prog_add(prog, priv->rx_ring_num);
if (IS_ERR(prog))
return PTR_ERR(prog);
}
-- 
2.9.3

Re: [PATCH 2/2] clk: pxa: fix pxa2xx_determine_rate return

[Robert Jarzmik]

Arnd Bergmann  writes:

> On Tuesday, November 8, 2016 7:01:57 PM CET Robert Jarzmik wrote:
>> Arnd Bergmann  writes:
>> If a non-exact match is found, either by closest_below or closest_above, 
>> rate is
>> set (rate = freqs[closest_xxx].cpll). And a couple of lines later after the
>> if/else, req->rate = rate is set as well, so I don't think this part of the
>> commit message is accurate.
>
> It is only set if rate is zero, and that normally is not the case here:
>
>if (!rate)
>req->rate = rate;
Ah ok, that's where the bug was lurking, if should have been "if (rate)".

But anyway, after comparing the end result of your code and mine, I find yours
more maintainable, especially the replacement of 'ret = 0'.

So let's proceed, thanks for finding this one out.
Acked-by: Robert Jarzmik 

--
Robert

Re: [PATCH 2/2] clk: pxa: fix pxa2xx_determine_rate return

[Robert Jarzmik]

Arnd Bergmann  writes:

> On Tuesday, November 8, 2016 7:01:57 PM CET Robert Jarzmik wrote:
>> Arnd Bergmann  writes:
>> If a non-exact match is found, either by closest_below or closest_above, 
>> rate is
>> set (rate = freqs[closest_xxx].cpll). And a couple of lines later after the
>> if/else, req->rate = rate is set as well, so I don't think this part of the
>> commit message is accurate.
>
> It is only set if rate is zero, and that normally is not the case here:
>
>if (!rate)
>req->rate = rate;
Ah ok, that's where the bug was lurking, if should have been "if (rate)".

But anyway, after comparing the end result of your code and mine, I find yours
more maintainable, especially the replacement of 'ret = 0'.

So let's proceed, thanks for finding this one out.
Acked-by: Robert Jarzmik 

--
Robert

Re: [PATCH for-next 09/11] IB/hns: Change qpn allocation to round-robin mode.

[Leon Romanovsky]

On Fri, Nov 04, 2016 at 04:36:31PM +, Salil Mehta wrote:
> From: "Wei Hu (Xavier)" 
>
> When using CM to establish connections, qp number that was freed
> just now will be rejected by ib core. To fix these problem, We
> change qpn allocation to round-robin mode. We added the round-robin
> mode for allocating resources using bitmap. We use round-robin mode
> for qp number and non round-robing mode for other resources like
> cq number, pd number etc.
>
> Signed-off-by: Wei Hu (Xavier) 
> Signed-off-by: Salil Mehta  

Reviewed-by: Leon Romanovsky 


signature.asc
Description: PGP signature

Re: [PATCH for-next 09/11] IB/hns: Change qpn allocation to round-robin mode.

[Leon Romanovsky]

On Fri, Nov 04, 2016 at 04:36:31PM +, Salil Mehta wrote:
> From: "Wei Hu (Xavier)" 
>
> When using CM to establish connections, qp number that was freed
> just now will be rejected by ib core. To fix these problem, We
> change qpn allocation to round-robin mode. We added the round-robin
> mode for allocating resources using bitmap. We use round-robin mode
> for qp number and non round-robing mode for other resources like
> cq number, pd number etc.
>
> Signed-off-by: Wei Hu (Xavier) 
> Signed-off-by: Salil Mehta  

Reviewed-by: Leon Romanovsky 


signature.asc
Description: PGP signature

Re: [PATCH for-next 03/11] IB/hns: Optimize the logic of allocating memory using APIs

[Leon Romanovsky]

On Fri, Nov 04, 2016 at 04:36:25PM +, Salil Mehta wrote:
> From: "Wei Hu (Xavier)" 
>
> This patch modified the logic of allocating memory using APIs in
> hns RoCE driver. We used kcalloc instead of kmalloc_array and
> bitmap_zero. And When kcalloc failed, call vzalloc to alloc
> memory.
>
> Signed-off-by: Wei Hu (Xavier) 
> Signed-off-by: Ping Zhang 
> Signed-off-by: Salil Mehta  
> ---
>  drivers/infiniband/hw/hns/hns_roce_mr.c |   15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/infiniband/hw/hns/hns_roce_mr.c 
> b/drivers/infiniband/hw/hns/hns_roce_mr.c
> index fb87883..d3dfb5f 100644
> --- a/drivers/infiniband/hw/hns/hns_roce_mr.c
> +++ b/drivers/infiniband/hw/hns/hns_roce_mr.c
> @@ -137,11 +137,12 @@ static int hns_roce_buddy_init(struct hns_roce_buddy 
> *buddy, int max_order)
>
>   for (i = 0; i <= buddy->max_order; ++i) {
>   s = BITS_TO_LONGS(1 << (buddy->max_order - i));
> - buddy->bits[i] = kmalloc_array(s, sizeof(long), GFP_KERNEL);
> - if (!buddy->bits[i])
> - goto err_out_free;
> -
> - bitmap_zero(buddy->bits[i], 1 << (buddy->max_order - i));
> + buddy->bits[i] = kcalloc(s, sizeof(long), GFP_KERNEL);
> + if (!buddy->bits[i]) {
> + buddy->bits[i] = vzalloc(s * sizeof(long));

I wonder, why don't you use directly vzalloc instead of kcalloc fallback?

> + if (!buddy->bits[i])
> + goto err_out_free;
> + }
>   }


signature.asc
Description: PGP signature

Re: [PATCH for-next 03/11] IB/hns: Optimize the logic of allocating memory using APIs

[Leon Romanovsky]

On Fri, Nov 04, 2016 at 04:36:25PM +, Salil Mehta wrote:
> From: "Wei Hu (Xavier)" 
>
> This patch modified the logic of allocating memory using APIs in
> hns RoCE driver. We used kcalloc instead of kmalloc_array and
> bitmap_zero. And When kcalloc failed, call vzalloc to alloc
> memory.
>
> Signed-off-by: Wei Hu (Xavier) 
> Signed-off-by: Ping Zhang 
> Signed-off-by: Salil Mehta  
> ---
>  drivers/infiniband/hw/hns/hns_roce_mr.c |   15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/infiniband/hw/hns/hns_roce_mr.c 
> b/drivers/infiniband/hw/hns/hns_roce_mr.c
> index fb87883..d3dfb5f 100644
> --- a/drivers/infiniband/hw/hns/hns_roce_mr.c
> +++ b/drivers/infiniband/hw/hns/hns_roce_mr.c
> @@ -137,11 +137,12 @@ static int hns_roce_buddy_init(struct hns_roce_buddy 
> *buddy, int max_order)
>
>   for (i = 0; i <= buddy->max_order; ++i) {
>   s = BITS_TO_LONGS(1 << (buddy->max_order - i));
> - buddy->bits[i] = kmalloc_array(s, sizeof(long), GFP_KERNEL);
> - if (!buddy->bits[i])
> - goto err_out_free;
> -
> - bitmap_zero(buddy->bits[i], 1 << (buddy->max_order - i));
> + buddy->bits[i] = kcalloc(s, sizeof(long), GFP_KERNEL);
> + if (!buddy->bits[i]) {
> + buddy->bits[i] = vzalloc(s * sizeof(long));

I wonder, why don't you use directly vzalloc instead of kcalloc fallback?

> + if (!buddy->bits[i])
> + goto err_out_free;
> + }
>   }


signature.asc
Description: PGP signature

Re: [PATCH 3/7] genirq/affinity: Handle pre/post vectors in irq_create_affinity_masks()

[Hannes Reinecke]

On 11/09/2016 02:15 AM, Christoph Hellwig wrote:

Only calculate the affinity for the main I/O vectors, and skip the
pre or post vectors specified by struct irq_affinity.

Also remove the irq_affinity cpumask argument that has never been used.
If we ever need it in the future we can pass it through struct
irq_affinity.

Signed-off-by: Christoph Hellwig 
Acked-by: Bjorn Helgaas 
---
 drivers/pci/msi.c |  6 --
 include/linux/interrupt.h |  4 ++--
 kernel/irq/affinity.c | 46 +-
 3 files changed, 31 insertions(+), 25 deletions(-)


Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH v4 1/3] leds: Introduce userspace leds driver

[Pavel Machek]

Hi!

> >+struct uleds_device {
> >+struct uleds_user_dev   user_dev;
> >+struct led_classdev led_cdev;
> >+struct mutexmutex;
> >+enum uleds_statestate;
> >+wait_queue_head_t   waitq;
> >+unsigned char   brightness;
> 
> I've just noticed that this is wrong, since LED subsystem
> brightness type is enum led_brightness, i.e. int.
> LED_FULL (255) value is a legacy enum value that can be overridden
> by max_brightness property.
> 
> Please submit a fix so that I could merge it with the original
> patch before sending it upstream.

Actually... perhaps you want to wait with merging the userspace driver
till the locking is solved in the LED subsystem? Maybe I'm wrong, but
I have feeling that userspace driver will have unusual requirements
w.r.t. locking, and that it would be good to have that solved,
first...

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


signature.asc
Description: Digital signature

Re: [PATCH 3/7] genirq/affinity: Handle pre/post vectors in irq_create_affinity_masks()

[Hannes Reinecke]

On 11/09/2016 02:15 AM, Christoph Hellwig wrote:

Only calculate the affinity for the main I/O vectors, and skip the
pre or post vectors specified by struct irq_affinity.

Also remove the irq_affinity cpumask argument that has never been used.
If we ever need it in the future we can pass it through struct
irq_affinity.

Signed-off-by: Christoph Hellwig 
Acked-by: Bjorn Helgaas 
---
 drivers/pci/msi.c |  6 --
 include/linux/interrupt.h |  4 ++--
 kernel/irq/affinity.c | 46 +-
 3 files changed, 31 insertions(+), 25 deletions(-)


Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH v4 1/3] leds: Introduce userspace leds driver

[Pavel Machek]

Hi!

> >+struct uleds_device {
> >+struct uleds_user_dev   user_dev;
> >+struct led_classdev led_cdev;
> >+struct mutexmutex;
> >+enum uleds_statestate;
> >+wait_queue_head_t   waitq;
> >+unsigned char   brightness;
> 
> I've just noticed that this is wrong, since LED subsystem
> brightness type is enum led_brightness, i.e. int.
> LED_FULL (255) value is a legacy enum value that can be overridden
> by max_brightness property.
> 
> Please submit a fix so that I could merge it with the original
> patch before sending it upstream.

Actually... perhaps you want to wait with merging the userspace driver
till the locking is solved in the LED subsystem? Maybe I'm wrong, but
I have feeling that userspace driver will have unusual requirements
w.r.t. locking, and that it would be good to have that solved,
first...

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


signature.asc
Description: Digital signature

Re: [PATCH 2/7] genirq/affinity: Handle pre/post vectors in irq_calc_affinity_vectors()

[Hannes Reinecke]

On 11/09/2016 02:15 AM, Christoph Hellwig wrote:

Only calculate the affinity for the main I/O vectors, and skip the
pre or post vectors specified by struct irq_affinity.

Also remove the irq_affinity cpumask argument that has never been used.
If we ever need it in the future we can pass it through struct
irq_affinity.

Signed-off-by: Christoph Hellwig 
---
 drivers/pci/msi.c |  8 
 include/linux/interrupt.h |  4 ++--
 kernel/irq/affinity.c | 24 ++--
 3 files changed, 16 insertions(+), 20 deletions(-)


Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH 2/7] genirq/affinity: Handle pre/post vectors in irq_calc_affinity_vectors()

[Hannes Reinecke]

On 11/09/2016 02:15 AM, Christoph Hellwig wrote:

Only calculate the affinity for the main I/O vectors, and skip the
pre or post vectors specified by struct irq_affinity.

Also remove the irq_affinity cpumask argument that has never been used.
If we ever need it in the future we can pass it through struct
irq_affinity.

Signed-off-by: Christoph Hellwig 
---
 drivers/pci/msi.c |  8 
 include/linux/interrupt.h |  4 ++--
 kernel/irq/affinity.c | 24 ++--
 3 files changed, 16 insertions(+), 20 deletions(-)


Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH 1/2] kernel: Move prctl and helpers from kernel/sys.c to new kernel/prctl.c

[Cyrill Gorcunov]

On Tue, Nov 08, 2016 at 04:18:13PM -0800, Josh Triplett wrote:
> This prepares for making prctl optional.
> 
> Signed-off-by: Josh Triplett 
> +
...
> +static int prctl_set_mm_exe_file(struct mm_struct *mm, unsigned int fd)
> +{
> + struct fd exe;
> + struct file *old_exe, *exe_file;
> + struct inode *inode;
> + int err;
> +
> + exe = fdget(fd);
> + if (!exe.file)
> + return -EBADF;
> +
> + inode = file_inode(exe.file);
> +
> + /*
> +  * Because the original mm->exe_file points to executable file, make
> +  * sure that this one is executable as well, to avoid breaking an
> +  * overall picture.
> +  */
> + err = -EACCES;
> + if (!S_ISREG(inode->i_mode) || path_noexec(>f_path))
> + goto exit;
> +
> + err = inode_permission(inode, MAY_EXEC);
> + if (err)
> + goto exit;
> +
> + /*
> +  * Forbid mm->exe_file change if old file still mapped.
> +  */
> + exe_file = get_mm_exe_file(mm);
> + err = -EBUSY;
> + if (exe_file) {
> + struct vm_area_struct *vma;
> +
> + down_read(>mmap_sem);
> + for (vma = mm->mmap; vma; vma = vma->vm_next) {
> + if (!vma->vm_file)
> + continue;
> + if (path_equal(>vm_file->f_path,
> +_file->f_path))
> + goto exit_err;
> + }
> +
> + up_read(>mmap_sem);
> + fput(exe_file);
> + }
> +
> + /*
> +  * The symlink can be changed only once, just to disallow arbitrary
> +  * transitions malicious software might bring in. This means one
> +  * could make a snapshot over all processes running and monitor
> +  * /proc/pid/exe changes to notice unusual activity if needed.
> +  */
> + err = -EPERM;
> + if (test_and_set_bit(MMF_EXE_FILE_CHANGED, >flags))
> + goto exit;

IIRC this snippet has been dropped in linux-next tree. Stas CC'ed.
The rest looks cool for me. Thanks!

Reviewed-by: Cyrill Gorcunov 

Re: [PATCH 1/2] kernel: Move prctl and helpers from kernel/sys.c to new kernel/prctl.c

[Cyrill Gorcunov]

On Tue, Nov 08, 2016 at 04:18:13PM -0800, Josh Triplett wrote:
> This prepares for making prctl optional.
> 
> Signed-off-by: Josh Triplett 
> +
...
> +static int prctl_set_mm_exe_file(struct mm_struct *mm, unsigned int fd)
> +{
> + struct fd exe;
> + struct file *old_exe, *exe_file;
> + struct inode *inode;
> + int err;
> +
> + exe = fdget(fd);
> + if (!exe.file)
> + return -EBADF;
> +
> + inode = file_inode(exe.file);
> +
> + /*
> +  * Because the original mm->exe_file points to executable file, make
> +  * sure that this one is executable as well, to avoid breaking an
> +  * overall picture.
> +  */
> + err = -EACCES;
> + if (!S_ISREG(inode->i_mode) || path_noexec(>f_path))
> + goto exit;
> +
> + err = inode_permission(inode, MAY_EXEC);
> + if (err)
> + goto exit;
> +
> + /*
> +  * Forbid mm->exe_file change if old file still mapped.
> +  */
> + exe_file = get_mm_exe_file(mm);
> + err = -EBUSY;
> + if (exe_file) {
> + struct vm_area_struct *vma;
> +
> + down_read(>mmap_sem);
> + for (vma = mm->mmap; vma; vma = vma->vm_next) {
> + if (!vma->vm_file)
> + continue;
> + if (path_equal(>vm_file->f_path,
> +_file->f_path))
> + goto exit_err;
> + }
> +
> + up_read(>mmap_sem);
> + fput(exe_file);
> + }
> +
> + /*
> +  * The symlink can be changed only once, just to disallow arbitrary
> +  * transitions malicious software might bring in. This means one
> +  * could make a snapshot over all processes running and monitor
> +  * /proc/pid/exe changes to notice unusual activity if needed.
> +  */
> + err = -EPERM;
> + if (test_and_set_bit(MMF_EXE_FILE_CHANGED, >flags))
> + goto exit;

IIRC this snippet has been dropped in linux-next tree. Stas CC'ed.
The rest looks cool for me. Thanks!

Reviewed-by: Cyrill Gorcunov 

Re: [PATCH] staging: iio: ad9832: allocate data before using

[Eva Rachel Retuya]

On Tue, Nov 08, 2016 at 03:00:49PM +0100, Arnd Bergmann wrote:
> The regulator changes assigned data to an uninitialized pointer:
> 
> drivers/staging/iio/frequency/ad9832.c: In function 'ad9832_probe':
> drivers/staging/iio/frequency/ad9832.c:214:11: error: 'st' may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> 
> This moves the allocation of the 'st' structure before its first
> use, as it should have been.
> 
> Fixes: 43a07e48af44 ("staging: iio: ad9832: clean-up regulator 'reg'")
> Fixes: a98461d79ba5 ("staging: iio: ad9832: add DVDD regulator")
> Signed-off-by: Arnd Bergmann 

Thank you, I completely missed this. Will be more careful next time.

Eva

> ---
>  drivers/staging/iio/frequency/ad9832.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/staging/iio/frequency/ad9832.c 
> b/drivers/staging/iio/frequency/ad9832.c
> index 639047fade30..a5b2f068168d 100644
> --- a/drivers/staging/iio/frequency/ad9832.c
> +++ b/drivers/staging/iio/frequency/ad9832.c
> @@ -211,6 +211,13 @@ static int ad9832_probe(struct spi_device *spi)
>   return -ENODEV;
>   }
>  
> + indio_dev = devm_iio_device_alloc(>dev, sizeof(*st));
> + if (!indio_dev)
> + return -ENOMEM;
> +
> + spi_set_drvdata(spi, indio_dev);
> + st = iio_priv(indio_dev);
> +
>   st->avdd = devm_regulator_get(>dev, "avdd");
>   if (IS_ERR(st->avdd))
>   return PTR_ERR(st->avdd);
> @@ -233,13 +240,6 @@ static int ad9832_probe(struct spi_device *spi)
>   goto error_disable_avdd;
>   }
>  
> - indio_dev = devm_iio_device_alloc(>dev, sizeof(*st));
> - if (!indio_dev) {
> - ret = -ENOMEM;
> - goto error_disable_dvdd;
> - }
> - spi_set_drvdata(spi, indio_dev);
> - st = iio_priv(indio_dev);
>   st->mclk = pdata->mclk;
>   st->spi = spi;
>  
> -- 
> 2.9.0
> 

Re: [PATCH] staging: iio: ad9832: allocate data before using

[Eva Rachel Retuya]

On Tue, Nov 08, 2016 at 03:00:49PM +0100, Arnd Bergmann wrote:
> The regulator changes assigned data to an uninitialized pointer:
> 
> drivers/staging/iio/frequency/ad9832.c: In function 'ad9832_probe':
> drivers/staging/iio/frequency/ad9832.c:214:11: error: 'st' may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> 
> This moves the allocation of the 'st' structure before its first
> use, as it should have been.
> 
> Fixes: 43a07e48af44 ("staging: iio: ad9832: clean-up regulator 'reg'")
> Fixes: a98461d79ba5 ("staging: iio: ad9832: add DVDD regulator")
> Signed-off-by: Arnd Bergmann 

Thank you, I completely missed this. Will be more careful next time.

Eva

> ---
>  drivers/staging/iio/frequency/ad9832.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/staging/iio/frequency/ad9832.c 
> b/drivers/staging/iio/frequency/ad9832.c
> index 639047fade30..a5b2f068168d 100644
> --- a/drivers/staging/iio/frequency/ad9832.c
> +++ b/drivers/staging/iio/frequency/ad9832.c
> @@ -211,6 +211,13 @@ static int ad9832_probe(struct spi_device *spi)
>   return -ENODEV;
>   }
>  
> + indio_dev = devm_iio_device_alloc(>dev, sizeof(*st));
> + if (!indio_dev)
> + return -ENOMEM;
> +
> + spi_set_drvdata(spi, indio_dev);
> + st = iio_priv(indio_dev);
> +
>   st->avdd = devm_regulator_get(>dev, "avdd");
>   if (IS_ERR(st->avdd))
>   return PTR_ERR(st->avdd);
> @@ -233,13 +240,6 @@ static int ad9832_probe(struct spi_device *spi)
>   goto error_disable_avdd;
>   }
>  
> - indio_dev = devm_iio_device_alloc(>dev, sizeof(*st));
> - if (!indio_dev) {
> - ret = -ENOMEM;
> - goto error_disable_dvdd;
> - }
> - spi_set_drvdata(spi, indio_dev);
> - st = iio_priv(indio_dev);
>   st->mclk = pdata->mclk;
>   st->spi = spi;
>  
> -- 
> 2.9.0
> 

Re: [PATCH v5 2/5] driver core: Functional dependencies tracking support

[Greg Kroah-Hartman]

On Tue, Nov 08, 2016 at 09:58:24PM +0100, Luis R. Rodriguez wrote:
> > > Furthermore -- how does this framework compare to Andrzej's resource 
> > > tracking
> > > solution? I confess I have not had a chance yet to review yet but in 
> > > light of
> > > this question it would be good to know if Andrzej's framework also 
> > > requires
> > > deferred probe as similar concerns would exist there as well.
> > 
> > I have no idea what "framework" you are talking about here, do you have
> > a pointer to patches?
> 
> I'm surprised given Andrzej did both Cc you on his patches [2] *and* chimed
> in on Rafael's patches to indicate that we likely can integrate PM concerns
> into his own "framework" [3]. There was no resolution to this discussion, 
> however
> its not IMHO sufficient to brush off Andrzej's points in particular because
> Andrzej *is* indicating that his framework:

Dude, those patches were from 2014!  I can't remember patches people
sent to me a month ago...

> - Eliminates deferred probe and resulting late_initcall(), consumer registers
> callbacks informing when given resources (clock, regulator, etc) becomes
> available
> - Properly handle resource disappearance (driver unbind, hotplug)
> - Track resources which are not vital to the device, but can influence 
> behavior
> - Offers simplified resource allocation
> - Can be easily expanded to help with power management
> 
> Granted I have not reviewed this yet but it at least was on my radar, and
> I do believe its worth reviewing this further given the generally expressed
> interest to see if we can have a common framework to address both ordering
> problems, suspend and probe. At a quick glance the "ghost provider" idea
> seems like a rather crazy idea but hey, there may be some goods in there.

>From what I remember, and I could be totally wrong, these patches were
way too complex and required that every subsystem change their
interfaces.  That's not going to work out well, but read the email
threads for the details...

> It was sad both Andrzej and yourself could not attend the complex dependencies
> tracks -- I think it would have been useful.

Sometimes real-life gets in the way of work, sorry :(

> I don't expect us to address a
> resolution to probe ordering immediately -- but I am in the hopes we at least
> can keep an open mind about the similarity of the problems and see if we can
> aim for a clean elegant solution that might help both.

I'll always review patches of what people come up with.

thanks,

greg k-h

Re: [PATCH v5 2/5] driver core: Functional dependencies tracking support

[Greg Kroah-Hartman]

On Tue, Nov 08, 2016 at 09:58:24PM +0100, Luis R. Rodriguez wrote:
> > > Furthermore -- how does this framework compare to Andrzej's resource 
> > > tracking
> > > solution? I confess I have not had a chance yet to review yet but in 
> > > light of
> > > this question it would be good to know if Andrzej's framework also 
> > > requires
> > > deferred probe as similar concerns would exist there as well.
> > 
> > I have no idea what "framework" you are talking about here, do you have
> > a pointer to patches?
> 
> I'm surprised given Andrzej did both Cc you on his patches [2] *and* chimed
> in on Rafael's patches to indicate that we likely can integrate PM concerns
> into his own "framework" [3]. There was no resolution to this discussion, 
> however
> its not IMHO sufficient to brush off Andrzej's points in particular because
> Andrzej *is* indicating that his framework:

Dude, those patches were from 2014!  I can't remember patches people
sent to me a month ago...

> - Eliminates deferred probe and resulting late_initcall(), consumer registers
> callbacks informing when given resources (clock, regulator, etc) becomes
> available
> - Properly handle resource disappearance (driver unbind, hotplug)
> - Track resources which are not vital to the device, but can influence 
> behavior
> - Offers simplified resource allocation
> - Can be easily expanded to help with power management
> 
> Granted I have not reviewed this yet but it at least was on my radar, and
> I do believe its worth reviewing this further given the generally expressed
> interest to see if we can have a common framework to address both ordering
> problems, suspend and probe. At a quick glance the "ghost provider" idea
> seems like a rather crazy idea but hey, there may be some goods in there.

>From what I remember, and I could be totally wrong, these patches were
way too complex and required that every subsystem change their
interfaces.  That's not going to work out well, but read the email
threads for the details...

> It was sad both Andrzej and yourself could not attend the complex dependencies
> tracks -- I think it would have been useful.

Sometimes real-life gets in the way of work, sorry :(

> I don't expect us to address a
> resolution to probe ordering immediately -- but I am in the hopes we at least
> can keep an open mind about the similarity of the problems and see if we can
> aim for a clean elegant solution that might help both.

I'll always review patches of what people come up with.

thanks,

greg k-h

Re: [PATCH] crypto: rsa: rename two rsa key files

[yjin]

Thanks for Herbert's reminder.
I have drop this patch in a previous mail.

Regards!
Yanjiang

On 2016年11月08日 20:09, Herbert Xu wrote:

yanjiang@windriver.com wrote:

From: Yanjiang Jin 

This is to eliminate the below compile error:

crypto/rsa_helper.c:19:29: fatal error: rsaprivkey-asn1.h: No such file or 
directory
#include "rsaprivkey-asn1.h"
 ^
compilation terminated.

Signed-off-by: Yanjiang Jin 

This patch is bogus.  The header files are meant to be generated.
Please find out why they are not being generated in your case.

Thanks,

Re: [PATCH] crypto: rsa: rename two rsa key files

[yjin]

Thanks for Herbert's reminder.
I have drop this patch in a previous mail.

Regards!
Yanjiang

On 2016年11月08日 20:09, Herbert Xu wrote:

yanjiang@windriver.com wrote:

From: Yanjiang Jin 

This is to eliminate the below compile error:

crypto/rsa_helper.c:19:29: fatal error: rsaprivkey-asn1.h: No such file or 
directory
#include "rsaprivkey-asn1.h"
 ^
compilation terminated.

Signed-off-by: Yanjiang Jin 

This patch is bogus.  The header files are meant to be generated.
Please find out why they are not being generated in your case.

Thanks,

[PATCH 1/2] rcu: Remove unnecessary condition in rcu_implicit_dynticks_qs

[Byungchul Park]

Given two conditions like,

COND 1. jiffies >= rdp->rsp->gp_start + 2 * jiffies_till_sched_qs
COND 2. jiffies >= rdp->rsp->gp_start + jiffies_till_sched_qs

A set of jiffies satisfying COND 2 includes another set satisfying
COND 1. Thus COND 1 can be removed from a condition, (COND 1 || COND 2).

Signed-off-by: Byungchul Park 
---
 kernel/rcu/tree.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 5d80925..d8e8859 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1220,9 +1220,7 @@ static int rcu_implicit_dynticks_qs(struct rcu_data *rdp,
}
 
/* And if it has been a really long time, kick the CPU as well. */
-   if (ULONG_CMP_GE(jiffies,
-rdp->rsp->gp_start + 2 * jiffies_till_sched_qs) ||
-   ULONG_CMP_GE(jiffies, rdp->rsp->gp_start + jiffies_till_sched_qs))
+   if (ULONG_CMP_GE(jiffies, rdp->rsp->gp_start + jiffies_till_sched_qs))
resched_cpu(rdp->cpu);  /* Force CPU into scheduler. */
 
return 0;
-- 
1.9.1

[PATCH 1/2] rcu: Remove unnecessary condition in rcu_implicit_dynticks_qs

[Byungchul Park]

Given two conditions like,

COND 1. jiffies >= rdp->rsp->gp_start + 2 * jiffies_till_sched_qs
COND 2. jiffies >= rdp->rsp->gp_start + jiffies_till_sched_qs

A set of jiffies satisfying COND 2 includes another set satisfying
COND 1. Thus COND 1 can be removed from a condition, (COND 1 || COND 2).

Signed-off-by: Byungchul Park 
---
 kernel/rcu/tree.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 5d80925..d8e8859 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1220,9 +1220,7 @@ static int rcu_implicit_dynticks_qs(struct rcu_data *rdp,
}
 
/* And if it has been a really long time, kick the CPU as well. */
-   if (ULONG_CMP_GE(jiffies,
-rdp->rsp->gp_start + 2 * jiffies_till_sched_qs) ||
-   ULONG_CMP_GE(jiffies, rdp->rsp->gp_start + jiffies_till_sched_qs))
+   if (ULONG_CMP_GE(jiffies, rdp->rsp->gp_start + jiffies_till_sched_qs))
resched_cpu(rdp->cpu);  /* Force CPU into scheduler. */
 
return 0;
-- 
1.9.1

[PATCH 2/2] rcu: Force resched_cpu when jiffies >= rcu_state.jiffies_resched

[Byungchul Park]

Currently rcu code forces CPU into scheduler when jiffies >=
rcu_state.gp_start + jiffies_till_sched_qs, via resched_cpu().

It would be better to force CPU into scheduler when jiffies >=
rcu_state.jiffies_resched, too.

Signed-off-by: Byungchul Park 
---
 kernel/rcu/tree.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index d8e8859..287f468 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1217,11 +1217,10 @@ static int rcu_implicit_dynticks_qs(struct rcu_data 
*rdp,
   READ_ONCE(*rcrmp) + rdp->rsp->flavor_mask);
}
rdp->rsp->jiffies_resched += 5; /* Re-enable beating. */
-   }
 
-   /* And if it has been a really long time, kick the CPU as well. */
-   if (ULONG_CMP_GE(jiffies, rdp->rsp->gp_start + jiffies_till_sched_qs))
+   /* And if it has been a really long time, kick the CPU as well. 
*/
resched_cpu(rdp->cpu);  /* Force CPU into scheduler. */
+   }
 
return 0;
 }
-- 
1.9.1

[PATCH 2/2] rcu: Force resched_cpu when jiffies >= rcu_state.jiffies_resched

[Byungchul Park]

Currently rcu code forces CPU into scheduler when jiffies >=
rcu_state.gp_start + jiffies_till_sched_qs, via resched_cpu().

It would be better to force CPU into scheduler when jiffies >=
rcu_state.jiffies_resched, too.

Signed-off-by: Byungchul Park 
---
 kernel/rcu/tree.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index d8e8859..287f468 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1217,11 +1217,10 @@ static int rcu_implicit_dynticks_qs(struct rcu_data 
*rdp,
   READ_ONCE(*rcrmp) + rdp->rsp->flavor_mask);
}
rdp->rsp->jiffies_resched += 5; /* Re-enable beating. */
-   }
 
-   /* And if it has been a really long time, kick the CPU as well. */
-   if (ULONG_CMP_GE(jiffies, rdp->rsp->gp_start + jiffies_till_sched_qs))
+   /* And if it has been a really long time, kick the CPU as well. 
*/
resched_cpu(rdp->cpu);  /* Force CPU into scheduler. */
+   }
 
return 0;
 }
-- 
1.9.1

Re: [PATCH 1/3] kbuild: add -fno-PIE

[Ingo Molnar]

* Michal Marek  wrote:

> On Fri, Nov 04, 2016 at 07:39:38PM +0100, Sebastian Andrzej Siewior wrote:
> > Debian started to build the gcc with -fPIE by default so the kernel
> > build ends before it starts properly with:
> > |kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
> > 
> > Also add to KBUILD_AFLAGS due to:
> > 
> > |gcc -Wp,-MD,arch/x86/entry/vdso/vdso32/.note.o.d … -mfentry 
> > -DCC_USING_FENTRY … vdso/vdso32/note.S
> > |arch/x86/entry/vdso/vdso32/note.S:1:0: sorry, unimplemented: -mfentry 
> > isn’t supported for 32-bit in combination with -fpic
> > 
> > Tagging it stable so it is possible to compile recent stable kernels as
> > well.
> > 
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Sebastian Andrzej Siewior 
> > ---
> >  Makefile | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/Makefile b/Makefile
> > index a2650f9c6a25..d61145ebf498 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -622,6 +622,8 @@ include arch/$(SRCARCH)/Makefile
> >  KBUILD_CFLAGS  += $(call cc-option,-fno-delete-null-pointer-checks,)
> >  KBUILD_CFLAGS  += $(call cc-disable-warning,maybe-uninitialized,)
> >  KBUILD_CFLAGS  += $(call cc-disable-warning,frame-address,)
> > +KBUILD_CFLAGS  += $(call cc-option,-fno-PIE)
> > +KBUILD_AFLAGS  += $(call cc-option,-fno-PIE)
> 
> Bad compiler. No pie for you.
> 
> I applied this one to kbuild.git. How about 2/3 and 3/3. Will these be
> merged via tip.git or shall I apply them as well?

I'd suggest applying them to the kbuild tree, as they are related.

Thanks,

Ingo

Re: [PATCH 1/3] kbuild: add -fno-PIE

[Ingo Molnar]

* Michal Marek  wrote:

> On Fri, Nov 04, 2016 at 07:39:38PM +0100, Sebastian Andrzej Siewior wrote:
> > Debian started to build the gcc with -fPIE by default so the kernel
> > build ends before it starts properly with:
> > |kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
> > 
> > Also add to KBUILD_AFLAGS due to:
> > 
> > |gcc -Wp,-MD,arch/x86/entry/vdso/vdso32/.note.o.d … -mfentry 
> > -DCC_USING_FENTRY … vdso/vdso32/note.S
> > |arch/x86/entry/vdso/vdso32/note.S:1:0: sorry, unimplemented: -mfentry 
> > isn’t supported for 32-bit in combination with -fpic
> > 
> > Tagging it stable so it is possible to compile recent stable kernels as
> > well.
> > 
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Sebastian Andrzej Siewior 
> > ---
> >  Makefile | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/Makefile b/Makefile
> > index a2650f9c6a25..d61145ebf498 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -622,6 +622,8 @@ include arch/$(SRCARCH)/Makefile
> >  KBUILD_CFLAGS  += $(call cc-option,-fno-delete-null-pointer-checks,)
> >  KBUILD_CFLAGS  += $(call cc-disable-warning,maybe-uninitialized,)
> >  KBUILD_CFLAGS  += $(call cc-disable-warning,frame-address,)
> > +KBUILD_CFLAGS  += $(call cc-option,-fno-PIE)
> > +KBUILD_AFLAGS  += $(call cc-option,-fno-PIE)
> 
> Bad compiler. No pie for you.
> 
> I applied this one to kbuild.git. How about 2/3 and 3/3. Will these be
> merged via tip.git or shall I apply them as well?

I'd suggest applying them to the kbuild tree, as they are related.

Thanks,

Ingo

Re: S3 resume regression [1cf4f629d9d2 ("cpu/hotplug: Move online calls to hotplugged cpu")]

[Linus Torvalds]

On Tue, Nov 8, 2016 at 7:54 PM, Feng Tang  wrote:
> On Wed, Nov 02, 2016 at 04:47:37AM +0800, Ville Syrjälä wrote:
>>
>> I left the thing running for the weekend and it failed 26 out of 16057
>> times with the 25ms timeout. Looks like it takes ~5 minutes to resume
>> when it fails, but eventually it does come back.
>
> Just came back from a travel. Yes, the 5 minutes delay may be due to the
> expiration of the HPET timer, counting from 0 to 0x for a 13M
> frequencey HPET takes about 300 seconds. After resume, it seems nobody
> arms it so my old patch forces to arm one event.

Ville, what happens if you disable HPET? Can you force the TSC with
"clocksource=tsc" or "tsc=reliable". Does resume work reliably then?

Or is this one of the CPU's where tsc just doesn't work?

  Linus

Re: S3 resume regression [1cf4f629d9d2 ("cpu/hotplug: Move online calls to hotplugged cpu")]

[Linus Torvalds]

On Tue, Nov 8, 2016 at 7:54 PM, Feng Tang  wrote:
> On Wed, Nov 02, 2016 at 04:47:37AM +0800, Ville Syrjälä wrote:
>>
>> I left the thing running for the weekend and it failed 26 out of 16057
>> times with the 25ms timeout. Looks like it takes ~5 minutes to resume
>> when it fails, but eventually it does come back.
>
> Just came back from a travel. Yes, the 5 minutes delay may be due to the
> expiration of the HPET timer, counting from 0 to 0x for a 13M
> frequencey HPET takes about 300 seconds. After resume, it seems nobody
> arms it so my old patch forces to arm one event.

Ville, what happens if you disable HPET? Can you force the TSC with
"clocksource=tsc" or "tsc=reliable". Does resume work reliably then?

Or is this one of the CPU's where tsc just doesn't work?

  Linus

Re: [PATCH] ASoC: lpass-platform: initialize dma channel number

[Kenneth Westfield]

On Tue, Nov 08, 2016 at 02:38:52PM +0100, Arnd Bergmann wrote:
> A bugfix accidentally removed the implicit initialization of the
> dma channel number, causing undefined behavior when
> v->alloc_dma_channel is NULL:
> 
> sound/soc/qcom/lpass-platform.c: In function ‘lpass_platform_pcmops_open’:
> sound/soc/qcom/lpass-platform.c:83:29: error: ‘dma_ch’ may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> 
> This adds back an explicit initialization to zero, restoring the
> previous behavior for that case.
> 
> Fixes: 022d00ee0b55 ("ASoC: lpass-platform: Fix broken pcm data usage")
> Signed-off-by: Arnd Bergmann 
> ---
>  sound/soc/qcom/lpass-platform.c | 3 +++
>  1 file changed, 3 insertions(+)

Good catch.

Acked-by: Kenneth Westfield 

-- 
Kenneth Westfield
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, 
a Linux Foundation Collaborative Project

Re: [PATCH] ASoC: lpass-platform: initialize dma channel number

[Kenneth Westfield]

On Tue, Nov 08, 2016 at 02:38:52PM +0100, Arnd Bergmann wrote:
> A bugfix accidentally removed the implicit initialization of the
> dma channel number, causing undefined behavior when
> v->alloc_dma_channel is NULL:
> 
> sound/soc/qcom/lpass-platform.c: In function ‘lpass_platform_pcmops_open’:
> sound/soc/qcom/lpass-platform.c:83:29: error: ‘dma_ch’ may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> 
> This adds back an explicit initialization to zero, restoring the
> previous behavior for that case.
> 
> Fixes: 022d00ee0b55 ("ASoC: lpass-platform: Fix broken pcm data usage")
> Signed-off-by: Arnd Bergmann 
> ---
>  sound/soc/qcom/lpass-platform.c | 3 +++
>  1 file changed, 3 insertions(+)

Good catch.

Acked-by: Kenneth Westfield 

-- 
Kenneth Westfield
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, 
a Linux Foundation Collaborative Project

Re: [Resend][PATCH] cpufreq: conservative: Decrease frequency faster when the timer deferred

[Viresh Kumar]

On 08-11-16, 21:25, Stratos Karafotis wrote:
> But this is the supposed behaviour of conservative governor. We want
> the CPU to increase the frequency in steps. The patch just resets
> the frequency to a lower frequency in case of idle.
> 
> For argument's sake, let's assume that the governor timer is never
> deferred and runs every sampling period even on completely idle CPU.

There are no timers now :)

> And let's assume, for example, a burst load that runs every 100ms
> for 20ms. The default sampling rate is also 20ms.
> What would conservative do in case of that burst load? It would
> increase the frequency by one freq step after 20ms and then it would
> decrease the frequency 4 times by one frequency step. Most probably
> on the next burst load, the CPU will run on min frequency.
> 
> I agree that maybe this is not ideal for performance but maybe this is
> how we want conservative governor to work (lazily increase and decrease
> frequency).

Idle periods are already accounted for while calculating system load by legacy
governors.

And the more and more I think about this, I am inclined towards your patch.
Maybe in a bit different form and commit log.

If we see how the governors were written initially, there were no deferred
timers. And so even if CPUs were idle, we will wake up to adjust the step.

Even if we want to make the behavior similar to that, then also we should
account of missed sampling periods both while decreasing or increasing
frequencies.

@Rafael: What do you think ?

-- 
viresh

Re: [Resend][PATCH] cpufreq: conservative: Decrease frequency faster when the timer deferred

[Viresh Kumar]

On 08-11-16, 21:25, Stratos Karafotis wrote:
> But this is the supposed behaviour of conservative governor. We want
> the CPU to increase the frequency in steps. The patch just resets
> the frequency to a lower frequency in case of idle.
> 
> For argument's sake, let's assume that the governor timer is never
> deferred and runs every sampling period even on completely idle CPU.

There are no timers now :)

> And let's assume, for example, a burst load that runs every 100ms
> for 20ms. The default sampling rate is also 20ms.
> What would conservative do in case of that burst load? It would
> increase the frequency by one freq step after 20ms and then it would
> decrease the frequency 4 times by one frequency step. Most probably
> on the next burst load, the CPU will run on min frequency.
> 
> I agree that maybe this is not ideal for performance but maybe this is
> how we want conservative governor to work (lazily increase and decrease
> frequency).

Idle periods are already accounted for while calculating system load by legacy
governors.

And the more and more I think about this, I am inclined towards your patch.
Maybe in a bit different form and commit log.

If we see how the governors were written initially, there were no deferred
timers. And so even if CPUs were idle, we will wake up to adjust the step.

Even if we want to make the behavior similar to that, then also we should
account of missed sampling periods both while decreasing or increasing
frequencies.

@Rafael: What do you think ?

-- 
viresh

[PATCH] cpupower: Warn if values are truncated in frequency-info

[Akshay Adiga]

frequency-info currently rounds the frequnecy values to 2 decimal places
while printing "available frequency steps". Hence frequencies with 3rd
decimal place being greater than 5 will be rounded to next higher number
like 2.227GHz will be rounded to 2.23Ghz. On setting this frequency,
using "cpupower frequency-set -f " ,if the value does not match,
then it will set to the next lowest frequency greater than provided
frequency value (according to the userspace governor).

Hence adding a warning if there are any cases where the displayed
frequency cannot be used directly to set a perticular frequency, and
insist the user to use the "-n" option.

Simple usecase where it give counter intuitive results :
bash# cpupower frequency-info
...
  available frequency steps: 2.43 GHz, 2.39 GHz, 2.36 GHz, 2.33 GHz,
2.29 GHz, 2.26 GHz, 2.23 GHz, 2.19 GHz, 2.16 GHz, 2.13 GHz

bash# cpupower frequency-info -n
...
available frequency steps: 2.427000 GHz, 2.394000 GHz, 2.36 GHz,
2.327000 GHz, 2.294000 GHz, 2.261000 GHz, 2.227000 GHz, 2.194000 GHz,
2.161000 GHz, 2.128000 GHz

bash# cpupower frequency-set -f 2.23Ghz

bash# cpupower frequency-info
...
 current CPU frequency: 2.26 GHz (asserted by call to hardware)

Signed-off-by: Akshay Adiga 
---
 tools/power/cpupower/utils/cpufreq-info.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/tools/power/cpupower/utils/cpufreq-info.c 
b/tools/power/cpupower/utils/cpufreq-info.c
index 590d12a..4f13b06 100644
--- a/tools/power/cpupower/utils/cpufreq-info.c
+++ b/tools/power/cpupower/utils/cpufreq-info.c
@@ -85,6 +85,7 @@ static void proc_cpufreq_output(void)
 }
 
 static int no_rounding;
+static int freq_info_truncated;
 static void print_speed(unsigned long speed)
 {
unsigned long tmp;
@@ -103,8 +104,10 @@ static void print_speed(unsigned long speed)
} else {
if (speed > 100) {
tmp = speed%1;
-   if (tmp >= 5000)
+   if (tmp >= 5000) {
+   freq_info_truncated = 1;
speed += 1;
+   }
printf("%u.%02u GHz", ((unsigned int) speed/100),
((unsigned int) (speed%100)/1));
} else if (speed > 10) {
@@ -243,6 +246,7 @@ static int get_boost_mode(unsigned int cpu)
printf(_("%.0f MHz max turbo 1 active cores\n"),
   ratio * bclk);
}
+
return 0;
 }
 
@@ -641,5 +645,12 @@ int cmd_freq_info(int argc, char **argv)
return ret;
printf("\n");
}
+
+   if (freq_info_truncated) {
+   printf("  Warning! Frequency values shown are rounded off\n");
+   printf("  To set frequency use frequency values provided\n");
+   printf("  by \"cpupower frequency-info -n \"\n");
+   }
+
return ret;
 }
-- 
2.5.5

[PATCH] cpupower: Warn if values are truncated in frequency-info

[Akshay Adiga]

frequency-info currently rounds the frequnecy values to 2 decimal places
while printing "available frequency steps". Hence frequencies with 3rd
decimal place being greater than 5 will be rounded to next higher number
like 2.227GHz will be rounded to 2.23Ghz. On setting this frequency,
using "cpupower frequency-set -f " ,if the value does not match,
then it will set to the next lowest frequency greater than provided
frequency value (according to the userspace governor).

Hence adding a warning if there are any cases where the displayed
frequency cannot be used directly to set a perticular frequency, and
insist the user to use the "-n" option.

Simple usecase where it give counter intuitive results :
bash# cpupower frequency-info
...
  available frequency steps: 2.43 GHz, 2.39 GHz, 2.36 GHz, 2.33 GHz,
2.29 GHz, 2.26 GHz, 2.23 GHz, 2.19 GHz, 2.16 GHz, 2.13 GHz

bash# cpupower frequency-info -n
...
available frequency steps: 2.427000 GHz, 2.394000 GHz, 2.36 GHz,
2.327000 GHz, 2.294000 GHz, 2.261000 GHz, 2.227000 GHz, 2.194000 GHz,
2.161000 GHz, 2.128000 GHz

bash# cpupower frequency-set -f 2.23Ghz

bash# cpupower frequency-info
...
 current CPU frequency: 2.26 GHz (asserted by call to hardware)

Signed-off-by: Akshay Adiga 
---
 tools/power/cpupower/utils/cpufreq-info.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/tools/power/cpupower/utils/cpufreq-info.c 
b/tools/power/cpupower/utils/cpufreq-info.c
index 590d12a..4f13b06 100644
--- a/tools/power/cpupower/utils/cpufreq-info.c
+++ b/tools/power/cpupower/utils/cpufreq-info.c
@@ -85,6 +85,7 @@ static void proc_cpufreq_output(void)
 }
 
 static int no_rounding;
+static int freq_info_truncated;
 static void print_speed(unsigned long speed)
 {
unsigned long tmp;
@@ -103,8 +104,10 @@ static void print_speed(unsigned long speed)
} else {
if (speed > 100) {
tmp = speed%1;
-   if (tmp >= 5000)
+   if (tmp >= 5000) {
+   freq_info_truncated = 1;
speed += 1;
+   }
printf("%u.%02u GHz", ((unsigned int) speed/100),
((unsigned int) (speed%100)/1));
} else if (speed > 10) {
@@ -243,6 +246,7 @@ static int get_boost_mode(unsigned int cpu)
printf(_("%.0f MHz max turbo 1 active cores\n"),
   ratio * bclk);
}
+
return 0;
 }
 
@@ -641,5 +645,12 @@ int cmd_freq_info(int argc, char **argv)
return ret;
printf("\n");
}
+
+   if (freq_info_truncated) {
+   printf("  Warning! Frequency values shown are rounded off\n");
+   printf("  To set frequency use frequency values provided\n");
+   printf("  by \"cpupower frequency-info -n \"\n");
+   }
+
return ret;
 }
-- 
2.5.5

Re: [PATCH v2 00/12] mm: page migration enhancement for thp

[Naoya Horiguchi]

On Wed, Nov 09, 2016 at 01:32:04PM +1100, Balbir Singh wrote:
> On 08/11/16 10:31, Naoya Horiguchi wrote:
> > Hi everyone,
> > 
> > I've updated thp migration patches for v4.9-rc2-mmotm-2016-10-27-18-27
> > with feedbacks for ver.1.
> > 
> > General description (no change since ver.1)
> > ===
> > 
> > This patchset enhances page migration functionality to handle thp migration
> > for various page migration's callers:
> >  - mbind(2)
> >  - move_pages(2)
> >  - migrate_pages(2)
> >  - cgroup/cpuset migration
> >  - memory hotremove
> >  - soft offline
> > 
> > The main benefit is that we can avoid unnecessary thp splits, which helps us
> > avoid performance decrease when your applications handles NUMA optimization 
> > on
> > their own.
> > 
> > The implementation is similar to that of normal page migration, the key 
> > point
> > is that we modify a pmd to a pmd migration entry in swap-entry like format.
> > 
> > Changes / Notes
> > ===
> > 
> > - pmd_present() in x86 checks _PAGE_PRESENT, _PAGE_PROTNONE and _PAGE_PSE
> >   bits together, which makes implementing thp migration a bit hard because
> >   _PAGE_PSE bit is currently used by soft-dirty in swap-entry format.
> >   I was advised to dropping _PAGE_PSE in pmd_present(), but I don't think
> >   of the justification, so I keep it in this version. Instead, my approach
> >   is to move _PAGE_SWP_SOFT_DIRTY to bit 6 (unused) and reserve bit 7 for
> >   pmd non-present cases.
> 
> Thanks, IIRC
> 
> pmd_present = _PAGE_PRESENT | _PAGE_PROTNONE | _PAGE_PSE
> 
> AutoNUMA balancing would change it to
> 
> pmd_present = _PAGE_PROTNONE | _PAGE_PSE
> 
> and PMD_SWP_SOFT_DIRTY would make it
> 
> pmd_present = _PAGE_PSE
> 
> What you seem to be suggesting in your comment is that
> 
> pmd_present should be _PAGE_PRESENT | _PAGE_PROTNONE

This (no _PAGE_PSE) was a possibile solution, and as I described I gave up
this solution, because I noticed that what I actually wanted was that
pmd_present() certainly returns false during thp migration and that's done
by moving _PAGE_SWP_SOFT_DIRTY. So

  pmd_present = _PAGE_PRESENT | _PAGE_PROTNONE | _PAGE_PSE

is still correct in this patchset.

> 
> Isn't that good enough?
> 
> For THP migration I guess we use
> 
> _PAGE_PRESENT | _PAGE_PROTNONE | is_migration_entry(pmd)

Though I might misread your notations, I hope that the following code
seems describe itself well.

  static inline int is_pmd_migration_entry(pmd_t pmd)   
 
  { 
 
  return !pmd_present(pmd) && 
is_migration_entry(pmd_to_swp_entry(pmd)); 
  } 
 

Thanks,
Naoya Horiguchi

> 
> 
> > 
> > - this patchset still covers only x86_64. Zi Yan posted a patch for ppc64
> >   and I think it's favorably received so that's fine. But there's unsolved
> >   minor suggestion by Aneesh, so I don't include it in this set, expecting
> >   that it will be updated/reposted.
> > 
> > - pte-mapped thp and doubly-mapped thp were not supported in ver.1, but
> >   this version should work for such kinds of thp.
> > 
> > - thp page cache is not tested yet, and it's at the head of my todo list
> >   for future version.
> > 
> > Any comments or advices are welcomed.
> 
> Balbir Singh
> 

Re: [PATCH v2 00/12] mm: page migration enhancement for thp

[Naoya Horiguchi]

On Wed, Nov 09, 2016 at 01:32:04PM +1100, Balbir Singh wrote:
> On 08/11/16 10:31, Naoya Horiguchi wrote:
> > Hi everyone,
> > 
> > I've updated thp migration patches for v4.9-rc2-mmotm-2016-10-27-18-27
> > with feedbacks for ver.1.
> > 
> > General description (no change since ver.1)
> > ===
> > 
> > This patchset enhances page migration functionality to handle thp migration
> > for various page migration's callers:
> >  - mbind(2)
> >  - move_pages(2)
> >  - migrate_pages(2)
> >  - cgroup/cpuset migration
> >  - memory hotremove
> >  - soft offline
> > 
> > The main benefit is that we can avoid unnecessary thp splits, which helps us
> > avoid performance decrease when your applications handles NUMA optimization 
> > on
> > their own.
> > 
> > The implementation is similar to that of normal page migration, the key 
> > point
> > is that we modify a pmd to a pmd migration entry in swap-entry like format.
> > 
> > Changes / Notes
> > ===
> > 
> > - pmd_present() in x86 checks _PAGE_PRESENT, _PAGE_PROTNONE and _PAGE_PSE
> >   bits together, which makes implementing thp migration a bit hard because
> >   _PAGE_PSE bit is currently used by soft-dirty in swap-entry format.
> >   I was advised to dropping _PAGE_PSE in pmd_present(), but I don't think
> >   of the justification, so I keep it in this version. Instead, my approach
> >   is to move _PAGE_SWP_SOFT_DIRTY to bit 6 (unused) and reserve bit 7 for
> >   pmd non-present cases.
> 
> Thanks, IIRC
> 
> pmd_present = _PAGE_PRESENT | _PAGE_PROTNONE | _PAGE_PSE
> 
> AutoNUMA balancing would change it to
> 
> pmd_present = _PAGE_PROTNONE | _PAGE_PSE
> 
> and PMD_SWP_SOFT_DIRTY would make it
> 
> pmd_present = _PAGE_PSE
> 
> What you seem to be suggesting in your comment is that
> 
> pmd_present should be _PAGE_PRESENT | _PAGE_PROTNONE

This (no _PAGE_PSE) was a possibile solution, and as I described I gave up
this solution, because I noticed that what I actually wanted was that
pmd_present() certainly returns false during thp migration and that's done
by moving _PAGE_SWP_SOFT_DIRTY. So

  pmd_present = _PAGE_PRESENT | _PAGE_PROTNONE | _PAGE_PSE

is still correct in this patchset.

> 
> Isn't that good enough?
> 
> For THP migration I guess we use
> 
> _PAGE_PRESENT | _PAGE_PROTNONE | is_migration_entry(pmd)

Though I might misread your notations, I hope that the following code
seems describe itself well.

  static inline int is_pmd_migration_entry(pmd_t pmd)   
 
  { 
 
  return !pmd_present(pmd) && 
is_migration_entry(pmd_to_swp_entry(pmd)); 
  } 
 

Thanks,
Naoya Horiguchi

> 
> 
> > 
> > - this patchset still covers only x86_64. Zi Yan posted a patch for ppc64
> >   and I think it's favorably received so that's fine. But there's unsolved
> >   minor suggestion by Aneesh, so I don't include it in this set, expecting
> >   that it will be updated/reposted.
> > 
> > - pte-mapped thp and doubly-mapped thp were not supported in ver.1, but
> >   this version should work for such kinds of thp.
> > 
> > - thp page cache is not tested yet, and it's at the head of my todo list
> >   for future version.
> > 
> > Any comments or advices are welcomed.
> 
> Balbir Singh
> 

Re: [PATCH 0/3] add ION driver for STIh4xx SoC

[Laura Abbott]

On 11/08/2016 01:18 AM, Benjamin Gaignard wrote:
> Ok so no more dev on ION but can we add ION drivers  like hisilicon does ?
> 

If we can agree upon bindings, yes I think it would make sense
to have more platform support. Ideally, it would translate over
to newer features as well.

Thanks,
Laura

Re: [PATCH 0/3] add ION driver for STIh4xx SoC

[Laura Abbott]

On 11/08/2016 01:18 AM, Benjamin Gaignard wrote:
> Ok so no more dev on ION but can we add ION drivers  like hisilicon does ?
> 

If we can agree upon bindings, yes I think it would make sense
to have more platform support. Ideally, it would translate over
to newer features as well.

Thanks,
Laura

linux-next: Tree for Nov 9

[Stephen Rothwell]

Hi all,

Changes since 20161108:

The drm-misc tree gained a build failure, so I used the version from
next-20161108.

The sound-asoc tree still had its build failure, so I used the version
from next-20161028.

The scsi-mkp tree gained conflicts against the block and scsi trees.

The rtc tree lost its build failure.

The akpm tree gained a conflict against the jc_docs tree.

Non-merge commits (relative to Linus' tree): 4645
 5193 files changed, 293049 insertions(+), 97254 deletions(-)



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

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

Below is a summary of the state of the merge.

I am currently merging 246 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (e3a00f68e426 Merge tag 'iommu-fixes-v4.9-rc4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (4efca4ed05cb kbuild: modversions for 
EXPORT_SYMBOL() for asm)
Merging arc-current/for-curr (0a0a047def15 ARCv2: MCIP: Use IDU_M_DISTRI_DEST 
mode if there is only 1 destination core)
Merging arm-current/fixes (6127d124ee4e ARM: wire up new pkey syscalls)
Merging m68k-current/for-linus (7e251bb21ae0 m68k: Fix ndelay() macro)
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (fb479e44a9e2 powerpc/64s: relocation, register 
save fixes for system reset interrupt)
Merging sparc/master (0c183d92b20b Merge tag 'spi-fix-v4.9-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi)
Merging net/master (fd0285a39b1c fib_trie: Correct /proc/net/route off by one 
error)
Merging ipsec/master (7f92083eb58f vti6: flush x-netns xfrm cache when vti 
interface is removed)
Merging netfilter/master (b73b8a1ba598 netfilter: nft_dup: do not use sreg_dev 
if the user doesn't specify it)
Merging ipvs/master (b73b8a1ba598 netfilter: nft_dup: do not use sreg_dev if 
the user doesn't specify it)
Merging wireless-drivers/master (d3532ea6ce4e brcmfmac: avoid 
maybe-uninitialized warning in brcmf_cfg80211_start_ap)
Merging mac80211/master (269ebce4531b xen-netfront: cast grant table reference 
first to type int)
Merging sound-current/for-linus (6809cd682b82 ALSA: info: Return error for 
invalid read/write)
Merging pci-current/for-linus (16d917b130d7 PCI: Don't attempt to claim shadow 
copies of ROM)
Merging driver-core.current/driver-core-linus (bdacd1b426db driver core: fix 
smatch warning on dev->bus check)
Merging tty.current/tty-linus (a909d3e63699 Linux 4.9-rc3)
Merging usb.current/usb-linus (7309aa847ead cdc-acm: fix uninitialized variable)
Merging usb-gadget-fixes/fixes (fd9afd3cbe40 usb: gadget: u_ether: remove 
interrupt throttling)
Merging usb-serial-fixes/usb-linus (9bfef729a3d1 USB: serial: ftdi_sio: add 
support for TI CC3200 LaunchPad)
Merging usb-chipidea-fixes/ci-for-usb-stable (991d5add50a5 usb: chipidea: host: 
fix NULL ptr dereference during shutdown)
Merging phy/fixes (4320f9d4c183 phy: sun4i: check PMU presence when poking 
unknown bit of pmu)
Merging staging.current/staging-linus (68fae2f3df45 staging: nvec: remove 
managed resource from PS2 driver)
Merging char-misc.current/char-misc-linus (f6b2db084b65 vmbus: make sysfs names 
consistent with PCI)
Merging input-current/for-linus (324ae0958cab Input: psmouse - cleanup 

linux-next: Tree for Nov 9

[Stephen Rothwell]

Hi all,

Changes since 20161108:

The drm-misc tree gained a build failure, so I used the version from
next-20161108.

The sound-asoc tree still had its build failure, so I used the version
from next-20161028.

The scsi-mkp tree gained conflicts against the block and scsi trees.

The rtc tree lost its build failure.

The akpm tree gained a conflict against the jc_docs tree.

Non-merge commits (relative to Linus' tree): 4645
 5193 files changed, 293049 insertions(+), 97254 deletions(-)



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

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

Below is a summary of the state of the merge.

I am currently merging 246 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (e3a00f68e426 Merge tag 'iommu-fixes-v4.9-rc4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (4efca4ed05cb kbuild: modversions for 
EXPORT_SYMBOL() for asm)
Merging arc-current/for-curr (0a0a047def15 ARCv2: MCIP: Use IDU_M_DISTRI_DEST 
mode if there is only 1 destination core)
Merging arm-current/fixes (6127d124ee4e ARM: wire up new pkey syscalls)
Merging m68k-current/for-linus (7e251bb21ae0 m68k: Fix ndelay() macro)
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (fb479e44a9e2 powerpc/64s: relocation, register 
save fixes for system reset interrupt)
Merging sparc/master (0c183d92b20b Merge tag 'spi-fix-v4.9-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi)
Merging net/master (fd0285a39b1c fib_trie: Correct /proc/net/route off by one 
error)
Merging ipsec/master (7f92083eb58f vti6: flush x-netns xfrm cache when vti 
interface is removed)
Merging netfilter/master (b73b8a1ba598 netfilter: nft_dup: do not use sreg_dev 
if the user doesn't specify it)
Merging ipvs/master (b73b8a1ba598 netfilter: nft_dup: do not use sreg_dev if 
the user doesn't specify it)
Merging wireless-drivers/master (d3532ea6ce4e brcmfmac: avoid 
maybe-uninitialized warning in brcmf_cfg80211_start_ap)
Merging mac80211/master (269ebce4531b xen-netfront: cast grant table reference 
first to type int)
Merging sound-current/for-linus (6809cd682b82 ALSA: info: Return error for 
invalid read/write)
Merging pci-current/for-linus (16d917b130d7 PCI: Don't attempt to claim shadow 
copies of ROM)
Merging driver-core.current/driver-core-linus (bdacd1b426db driver core: fix 
smatch warning on dev->bus check)
Merging tty.current/tty-linus (a909d3e63699 Linux 4.9-rc3)
Merging usb.current/usb-linus (7309aa847ead cdc-acm: fix uninitialized variable)
Merging usb-gadget-fixes/fixes (fd9afd3cbe40 usb: gadget: u_ether: remove 
interrupt throttling)
Merging usb-serial-fixes/usb-linus (9bfef729a3d1 USB: serial: ftdi_sio: add 
support for TI CC3200 LaunchPad)
Merging usb-chipidea-fixes/ci-for-usb-stable (991d5add50a5 usb: chipidea: host: 
fix NULL ptr dereference during shutdown)
Merging phy/fixes (4320f9d4c183 phy: sun4i: check PMU presence when poking 
unknown bit of pmu)
Merging staging.current/staging-linus (68fae2f3df45 staging: nvec: remove 
managed resource from PS2 driver)
Merging char-misc.current/char-misc-linus (f6b2db084b65 vmbus: make sysfs names 
consistent with PCI)
Merging input-current/for-linus (324ae0958cab Input: psmouse - cleanup 

Re: support for partial irq affinity assignment V3

[Jens Axboe]

On 11/08/2016 06:15 PM, Christoph Hellwig wrote:

This series adds support for automatic interrupt assignment to devices
that have a few vectors that are set aside for admin or config purposes
and thus should not fall into the general per-cpu assginment pool.

The first patch adds that support to the core IRQ and PCI/msi code,
and the second is a small tweak to a block layer helper to make use
of it.  I'd love to have both go into the same tree so that consumers
of this (e.g. the virtio, scsi and rdma trees) only need to pull in
one of these trees as dependency.


Series looks good to me, you can add my Acked-by to all of them.

--
Jens Axboe

Re: support for partial irq affinity assignment V3

[Jens Axboe]

On 11/08/2016 06:15 PM, Christoph Hellwig wrote:

This series adds support for automatic interrupt assignment to devices
that have a few vectors that are set aside for admin or config purposes
and thus should not fall into the general per-cpu assginment pool.

The first patch adds that support to the core IRQ and PCI/msi code,
and the second is a small tweak to a block layer helper to make use
of it.  I'd love to have both go into the same tree so that consumers
of this (e.g. the virtio, scsi and rdma trees) only need to pull in
one of these trees as dependency.


Series looks good to me, you can add my Acked-by to all of them.

--
Jens Axboe

[PATCH 04/11] mtd: nand: denali: remove detect_partition_feature()

[Masahiro Yamada]

The denali->fwblks is set by detect_partition_feature(), but it is
not referenced from anywhere.  That means the struct member fwblks
and the whole of detect_partition_feature() are unneeded.

The comment block implies this function is only for Intel platforms.
I found drivers/staging/spectra used to exist, but it was deleted by
commit be7f39c5ecf5 ("Staging: delete spectra driver") 5 years ago.

So, I guess nobody would need this function any more.

Signed-off-by: Masahiro Yamada 
---

 drivers/mtd/nand/denali.c | 29 -
 drivers/mtd/nand/denali.h |  9 -
 2 files changed, 38 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index d6f1b29..80d3e26 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -473,33 +473,6 @@ static void detect_max_banks(struct denali_nand_info 
*denali)
denali->max_banks = 1 << (features & FEATURES__N_BANKS);
 }
 
-static void detect_partition_feature(struct denali_nand_info *denali)
-{
-   /*
-* For MRST platform, denali->fwblks represent the
-* number of blocks firmware is taken,
-* FW is in protect partition and MTD driver has no
-* permission to access it. So let driver know how many
-* blocks it can't touch.
-*/
-   if (ioread32(denali->flash_reg + FEATURES) & FEATURES__PARTITION) {
-   if ((ioread32(denali->flash_reg + PERM_SRC_ID(1)) &
-   PERM_SRC_ID__SRCID) == SPECTRA_PARTITION_ID) {
-   denali->fwblks =
-   ((ioread32(denali->flash_reg + MIN_MAX_BANK(1)) &
- MIN_MAX_BANK__MIN_VALUE) *
-denali->blksperchip)
-   +
-   (ioread32(denali->flash_reg + MIN_BLK_ADDR(1)) &
-   MIN_BLK_ADDR__VALUE);
-   } else {
-   denali->fwblks = SPECTRA_START_BLOCK;
-   }
-   } else {
-   denali->fwblks = SPECTRA_START_BLOCK;
-   }
-}
-
 static uint16_t denali_nand_timing_set(struct denali_nand_info *denali)
 {
uint16_t status = PASS;
@@ -551,8 +524,6 @@ static uint16_t denali_nand_timing_set(struct 
denali_nand_info *denali)
 
find_valid_banks(denali);
 
-   detect_partition_feature(denali);
-
/*
 * If the user specified to override the default timings
 * with a specific ONFI mode, we apply those changes here.
diff --git a/drivers/mtd/nand/denali.h b/drivers/mtd/nand/denali.h
index 0ce7344..7c0800d 100644
--- a/drivers/mtd/nand/denali.h
+++ b/drivers/mtd/nand/denali.h
@@ -383,14 +383,6 @@
 #define CLK_X  5
 #define CLK_MULTI 4
 
-/* spectraswconfig.h */
-#define CMD_DMA 0
-
-#define SPECTRA_PARTITION_ID0
-/ Block Table and Reserved Block Parameters */
-#define SPECTRA_START_BLOCK 3
-#define NUM_FREE_BLOCKS_GATE30
-
 /* KBV - Updated to LNW scratch register address */
 #define SCRATCH_REG_ADDRCONFIG_MTD_NAND_DENALI_SCRATCH_REG_ADDR
 #define SCRATCH_REG_SIZE64
@@ -470,7 +462,6 @@ struct denali_nand_info {
int irq;
 
uint32_t devnum;/* represent how many nands connected */
-   uint32_t fwblks; /* represent how many blocks FW used */
uint32_t totalblks;
uint32_t blksperchip;
uint32_t bbtskipbytes;
-- 
1.9.1

[PATCH 04/11] mtd: nand: denali: remove detect_partition_feature()

[Masahiro Yamada]

The denali->fwblks is set by detect_partition_feature(), but it is
not referenced from anywhere.  That means the struct member fwblks
and the whole of detect_partition_feature() are unneeded.

The comment block implies this function is only for Intel platforms.
I found drivers/staging/spectra used to exist, but it was deleted by
commit be7f39c5ecf5 ("Staging: delete spectra driver") 5 years ago.

So, I guess nobody would need this function any more.

Signed-off-by: Masahiro Yamada 
---

 drivers/mtd/nand/denali.c | 29 -
 drivers/mtd/nand/denali.h |  9 -
 2 files changed, 38 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index d6f1b29..80d3e26 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -473,33 +473,6 @@ static void detect_max_banks(struct denali_nand_info 
*denali)
denali->max_banks = 1 << (features & FEATURES__N_BANKS);
 }
 
-static void detect_partition_feature(struct denali_nand_info *denali)
-{
-   /*
-* For MRST platform, denali->fwblks represent the
-* number of blocks firmware is taken,
-* FW is in protect partition and MTD driver has no
-* permission to access it. So let driver know how many
-* blocks it can't touch.
-*/
-   if (ioread32(denali->flash_reg + FEATURES) & FEATURES__PARTITION) {
-   if ((ioread32(denali->flash_reg + PERM_SRC_ID(1)) &
-   PERM_SRC_ID__SRCID) == SPECTRA_PARTITION_ID) {
-   denali->fwblks =
-   ((ioread32(denali->flash_reg + MIN_MAX_BANK(1)) &
- MIN_MAX_BANK__MIN_VALUE) *
-denali->blksperchip)
-   +
-   (ioread32(denali->flash_reg + MIN_BLK_ADDR(1)) &
-   MIN_BLK_ADDR__VALUE);
-   } else {
-   denali->fwblks = SPECTRA_START_BLOCK;
-   }
-   } else {
-   denali->fwblks = SPECTRA_START_BLOCK;
-   }
-}
-
 static uint16_t denali_nand_timing_set(struct denali_nand_info *denali)
 {
uint16_t status = PASS;
@@ -551,8 +524,6 @@ static uint16_t denali_nand_timing_set(struct 
denali_nand_info *denali)
 
find_valid_banks(denali);
 
-   detect_partition_feature(denali);
-
/*
 * If the user specified to override the default timings
 * with a specific ONFI mode, we apply those changes here.
diff --git a/drivers/mtd/nand/denali.h b/drivers/mtd/nand/denali.h
index 0ce7344..7c0800d 100644
--- a/drivers/mtd/nand/denali.h
+++ b/drivers/mtd/nand/denali.h
@@ -383,14 +383,6 @@
 #define CLK_X  5
 #define CLK_MULTI 4
 
-/* spectraswconfig.h */
-#define CMD_DMA 0
-
-#define SPECTRA_PARTITION_ID0
-/ Block Table and Reserved Block Parameters */
-#define SPECTRA_START_BLOCK 3
-#define NUM_FREE_BLOCKS_GATE30
-
 /* KBV - Updated to LNW scratch register address */
 #define SCRATCH_REG_ADDRCONFIG_MTD_NAND_DENALI_SCRATCH_REG_ADDR
 #define SCRATCH_REG_SIZE64
@@ -470,7 +462,6 @@ struct denali_nand_info {
int irq;
 
uint32_t devnum;/* represent how many nands connected */
-   uint32_t fwblks; /* represent how many blocks FW used */
uint32_t totalblks;
uint32_t blksperchip;
uint32_t bbtskipbytes;
-- 
1.9.1

[PATCH 01/11] mtd: nand: denali: remove unneeded includes

[Masahiro Yamada]

The driver calls devm_kzalloc()/devm_kfree() to allocate/free memory.
They are declared in , not in .

Signed-off-by: Masahiro Yamada 
---

 drivers/mtd/nand/denali.c | 1 -
 drivers/mtd/nand/denali_dt.c  | 1 -
 drivers/mtd/nand/denali_pci.c | 1 -
 3 files changed, 3 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 7e2c650..062d5b5 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -21,7 +21,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/drivers/mtd/nand/denali_dt.c b/drivers/mtd/nand/denali_dt.c
index f821dc1..5607fcd 100644
--- a/drivers/mtd/nand/denali_dt.c
+++ b/drivers/mtd/nand/denali_dt.c
@@ -21,7 +21,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "denali.h"
 
diff --git a/drivers/mtd/nand/denali_pci.c b/drivers/mtd/nand/denali_pci.c
index de31514..ac84323 100644
--- a/drivers/mtd/nand/denali_pci.c
+++ b/drivers/mtd/nand/denali_pci.c
@@ -14,7 +14,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "denali.h"
 
-- 
1.9.1

[PATCH 02/11] mtd: nand: denali: remove unused struct member denali_nand_info::idx

[Masahiro Yamada]

The struct member "idx" was used as an index for debug_array long
ago, but the DEBUG_DENALI feature was removed by commit 7cfffac06ca0
("nand/denali: use dev_xx debug function to replace nand_dbg_print
and some printk").  Since then, this has been only initialized, but
never referenced.

Signed-off-by: Masahiro Yamada 
---

 drivers/mtd/nand/denali.c | 2 --
 drivers/mtd/nand/denali.h | 1 -
 2 files changed, 3 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 062d5b5..51ddb84 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -1436,8 +1436,6 @@ static int denali_ooblayout_free(struct mtd_info *mtd, 
int section,
 /* initialize driver data structures */
 static void denali_drv_init(struct denali_nand_info *denali)
 {
-   denali->idx = 0;
-
/* setup interrupt handler */
/*
 * the completion object will be used to notify
diff --git a/drivers/mtd/nand/denali.h b/drivers/mtd/nand/denali.h
index e7ab486..0ce7344 100644
--- a/drivers/mtd/nand/denali.h
+++ b/drivers/mtd/nand/denali.h
@@ -467,7 +467,6 @@ struct denali_nand_info {
spinlock_t irq_lock;
uint32_t irq_status;
int irq_debug_array[32];
-   int idx;
int irq;
 
uint32_t devnum;/* represent how many nands connected */
-- 
1.9.1

[PATCH 01/11] mtd: nand: denali: remove unneeded includes

[Masahiro Yamada]

The driver calls devm_kzalloc()/devm_kfree() to allocate/free memory.
They are declared in , not in .

Signed-off-by: Masahiro Yamada 
---

 drivers/mtd/nand/denali.c | 1 -
 drivers/mtd/nand/denali_dt.c  | 1 -
 drivers/mtd/nand/denali_pci.c | 1 -
 3 files changed, 3 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 7e2c650..062d5b5 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -21,7 +21,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/drivers/mtd/nand/denali_dt.c b/drivers/mtd/nand/denali_dt.c
index f821dc1..5607fcd 100644
--- a/drivers/mtd/nand/denali_dt.c
+++ b/drivers/mtd/nand/denali_dt.c
@@ -21,7 +21,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "denali.h"
 
diff --git a/drivers/mtd/nand/denali_pci.c b/drivers/mtd/nand/denali_pci.c
index de31514..ac84323 100644
--- a/drivers/mtd/nand/denali_pci.c
+++ b/drivers/mtd/nand/denali_pci.c
@@ -14,7 +14,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "denali.h"
 
-- 
1.9.1

[PATCH 02/11] mtd: nand: denali: remove unused struct member denali_nand_info::idx

[Masahiro Yamada]

The struct member "idx" was used as an index for debug_array long
ago, but the DEBUG_DENALI feature was removed by commit 7cfffac06ca0
("nand/denali: use dev_xx debug function to replace nand_dbg_print
and some printk").  Since then, this has been only initialized, but
never referenced.

Signed-off-by: Masahiro Yamada 
---

 drivers/mtd/nand/denali.c | 2 --
 drivers/mtd/nand/denali.h | 1 -
 2 files changed, 3 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 062d5b5..51ddb84 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -1436,8 +1436,6 @@ static int denali_ooblayout_free(struct mtd_info *mtd, 
int section,
 /* initialize driver data structures */
 static void denali_drv_init(struct denali_nand_info *denali)
 {
-   denali->idx = 0;
-
/* setup interrupt handler */
/*
 * the completion object will be used to notify
diff --git a/drivers/mtd/nand/denali.h b/drivers/mtd/nand/denali.h
index e7ab486..0ce7344 100644
--- a/drivers/mtd/nand/denali.h
+++ b/drivers/mtd/nand/denali.h
@@ -467,7 +467,6 @@ struct denali_nand_info {
spinlock_t irq_lock;
uint32_t irq_status;
int irq_debug_array[32];
-   int idx;
int irq;
 
uint32_t devnum;/* represent how many nands connected */
-- 
1.9.1

[PATCH 03/11] mtd: nand: denali: remove bogus comment about interrupt handler setup

[Masahiro Yamada]

The interrupt handler is setup in denali_init(), not in
denali_drv_init().  This comment is false.

Such a comment adds no value, so just delete it instead of move.

Signed-off-by: Masahiro Yamada 
---

 drivers/mtd/nand/denali.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 51ddb84..d6f1b29 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -1436,7 +1436,6 @@ static int denali_ooblayout_free(struct mtd_info *mtd, 
int section,
 /* initialize driver data structures */
 static void denali_drv_init(struct denali_nand_info *denali)
 {
-   /* setup interrupt handler */
/*
 * the completion object will be used to notify
 * the callee that the interrupt is done
-- 
1.9.1

[PATCH 03/11] mtd: nand: denali: remove bogus comment about interrupt handler setup

[Masahiro Yamada]

The interrupt handler is setup in denali_init(), not in
denali_drv_init().  This comment is false.

Such a comment adds no value, so just delete it instead of move.

Signed-off-by: Masahiro Yamada 
---

 drivers/mtd/nand/denali.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 51ddb84..d6f1b29 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -1436,7 +1436,6 @@ static int denali_ooblayout_free(struct mtd_info *mtd, 
int section,
 /* initialize driver data structures */
 static void denali_drv_init(struct denali_nand_info *denali)
 {
-   /* setup interrupt handler */
/*
 * the completion object will be used to notify
 * the callee that the interrupt is done
-- 
1.9.1

[PATCH 00/11] mtd: nand: denali: first round of cleanups of Denali NAND driver

[Masahiro Yamada]

I am tackling on this driver to use it for my SoCs.
The difficulty is a bunch of platform specific stuff
(more specifically, Intel MRST specific) is hard-coded in this driver.

I need lots of rework to utilize the driver for generic cases,
but at the same time, I found the driver code is really dirty,
lots of unused code, odd comments, etc.

The first thing I needed to do was to clean up the code.
My work is still under the way, but I decided to drop this series
for now.  I hope this series is easy to review, so I guess
splitting into a small chunks is better than a one-shot patch bomb.



Masahiro Yamada (11):
  mtd: nand: denali: remove unneeded  includes
  mtd: nand: denali: remove unused struct member denali_nand_info::idx
  mtd: nand: denali: remove bogus comment about interrupt handler setup
  mtd: nand: denali: remove detect_partition_feature()
  mtd: nand: denali: remove "Spectra:" prefix from printk strings
  mtd: nand: denali: remove unused struct member totalblks, blksperchip
  mtd: nand: denali: use managed devm_irq_request()
  mtd: nand: denali: return error code from devm_request_irq() on error
  mtd: nand: denali: return error code from nand_scan_ident/tail on
error
  mtd: nand: denali: remove unneeded parentheses
  mtd: nand: denali: remove debug lines of __FILE__, __LINE__, __func__

 drivers/mtd/nand/denali.c | 101 +-
 drivers/mtd/nand/denali.h |  12 -
 drivers/mtd/nand/denali_dt.c  |   1 -
 drivers/mtd/nand/denali_pci.c |   1 -
 4 files changed, 21 insertions(+), 94 deletions(-)

-- 
1.9.1

[PATCH 05/11] mtd: nand: denali: remove "Spectra:" prefix from printk strings

[Masahiro Yamada]

As far as I understood from the Kconfig menu deleted by commit
be7f39c5ecf5 ("Staging: delete spectra driver"), the "Spectra" is
specific to Intel Moorestown Platform.

The Denali NAND controller IP is used for various SoCs such as
Altera SOCFPGA, Socionext UniPhier, etc.  The platform specific
strings are not preferred in this driver.

Signed-off-by: Masahiro Yamada 
---

As an ARM-SoC developer, I only need denali.c and denali_dt.c.

I see some "Spectra:" in drivers/mtd/nand/denali_pci.c as well.
I was not quite sure if they are needed or not.
If desired, I can update this patch to remove them too.


 drivers/mtd/nand/denali.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 80d3e26..78d795b 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -402,7 +402,7 @@ static void get_hynix_nand_para(struct denali_nand_info 
*denali,
break;
default:
dev_warn(denali->dev,
-"Spectra: Unknown Hynix NAND (Device ID: 0x%x).\n"
+"Unknown Hynix NAND (Device ID: 0x%x).\n"
 "Will use default parameter values instead.\n",
 device_id);
}
@@ -1458,7 +1458,7 @@ int denali_init(struct denali_nand_info *denali)
 */
if (request_irq(denali->irq, denali_isr, IRQF_SHARED,
DENALI_NAND_NAME, denali)) {
-   pr_err("Spectra: Unable to allocate IRQ\n");
+   dev_err(denali->dev, "Unable to request IRQ\n");
return -ENODEV;
}
 
@@ -1495,7 +1495,7 @@ int denali_init(struct denali_nand_info *denali)
/* Is 32-bit DMA supported? */
ret = dma_set_mask(denali->dev, DMA_BIT_MASK(32));
if (ret) {
-   pr_err("Spectra: no usable DMA configuration\n");
+   dev_err(denali->dev, "no usable DMA configuration\n");
goto failed_req_irq;
}
 
@@ -1503,7 +1503,7 @@ int denali_init(struct denali_nand_info *denali)
 mtd->writesize + mtd->oobsize,
 DMA_BIDIRECTIONAL);
if (dma_mapping_error(denali->dev, denali->buf.dma_buf)) {
-   dev_err(denali->dev, "Spectra: failed to map DMA buffer\n");
+   dev_err(denali->dev, "failed to map DMA buffer\n");
ret = -EIO;
goto failed_req_irq;
}
@@ -1598,8 +1598,7 @@ int denali_init(struct denali_nand_info *denali)
 
ret = mtd_device_register(mtd, NULL, 0);
if (ret) {
-   dev_err(denali->dev, "Spectra: Failed to register MTD: %d\n",
-   ret);
+   dev_err(denali->dev, "Failed to register MTD: %d\n", ret);
goto failed_req_irq;
}
return 0;
-- 
1.9.1

[PATCH 06/11] mtd: nand: denali: remove unused struct member totalblks, blksperchip

[Masahiro Yamada]

The denali->blksperchip is set, but not referenced any more.  The
denali->totalblks is used only for calculating denali->blksperchip.
Both of them are unneeded.

Signed-off-by: Masahiro Yamada 
---

 drivers/mtd/nand/denali.c | 8 
 drivers/mtd/nand/denali.h | 2 --
 2 files changed, 10 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 78d795b..548278b 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -1573,14 +1573,6 @@ int denali_init(struct denali_nand_info *denali)
denali->nand.ecc.bytes *= denali->devnum;
denali->nand.ecc.strength *= denali->devnum;
 
-   /*
-* Let driver know the total blocks number and how many blocks
-* contained by each nand chip. blksperchip will help driver to
-* know how many blocks is taken by FW.
-*/
-   denali->totalblks = mtd->size >> denali->nand.phys_erase_shift;
-   denali->blksperchip = denali->totalblks / denali->nand.numchips;
-
/* override the default read operations */
denali->nand.ecc.size = ECC_SECTOR_SIZE * denali->devnum;
denali->nand.ecc.read_page = denali_read_page;
diff --git a/drivers/mtd/nand/denali.h b/drivers/mtd/nand/denali.h
index 7c0800d..ea22191 100644
--- a/drivers/mtd/nand/denali.h
+++ b/drivers/mtd/nand/denali.h
@@ -462,8 +462,6 @@ struct denali_nand_info {
int irq;
 
uint32_t devnum;/* represent how many nands connected */
-   uint32_t totalblks;
-   uint32_t blksperchip;
uint32_t bbtskipbytes;
uint32_t max_banks;
 };
-- 
1.9.1

[PATCH 00/11] mtd: nand: denali: first round of cleanups of Denali NAND driver

[Masahiro Yamada]

I am tackling on this driver to use it for my SoCs.
The difficulty is a bunch of platform specific stuff
(more specifically, Intel MRST specific) is hard-coded in this driver.

I need lots of rework to utilize the driver for generic cases,
but at the same time, I found the driver code is really dirty,
lots of unused code, odd comments, etc.

The first thing I needed to do was to clean up the code.
My work is still under the way, but I decided to drop this series
for now.  I hope this series is easy to review, so I guess
splitting into a small chunks is better than a one-shot patch bomb.



Masahiro Yamada (11):
  mtd: nand: denali: remove unneeded  includes
  mtd: nand: denali: remove unused struct member denali_nand_info::idx
  mtd: nand: denali: remove bogus comment about interrupt handler setup
  mtd: nand: denali: remove detect_partition_feature()
  mtd: nand: denali: remove "Spectra:" prefix from printk strings
  mtd: nand: denali: remove unused struct member totalblks, blksperchip
  mtd: nand: denali: use managed devm_irq_request()
  mtd: nand: denali: return error code from devm_request_irq() on error
  mtd: nand: denali: return error code from nand_scan_ident/tail on
error
  mtd: nand: denali: remove unneeded parentheses
  mtd: nand: denali: remove debug lines of __FILE__, __LINE__, __func__

 drivers/mtd/nand/denali.c | 101 +-
 drivers/mtd/nand/denali.h |  12 -
 drivers/mtd/nand/denali_dt.c  |   1 -
 drivers/mtd/nand/denali_pci.c |   1 -
 4 files changed, 21 insertions(+), 94 deletions(-)

-- 
1.9.1

[PATCH 05/11] mtd: nand: denali: remove "Spectra:" prefix from printk strings

[Masahiro Yamada]

As far as I understood from the Kconfig menu deleted by commit
be7f39c5ecf5 ("Staging: delete spectra driver"), the "Spectra" is
specific to Intel Moorestown Platform.

The Denali NAND controller IP is used for various SoCs such as
Altera SOCFPGA, Socionext UniPhier, etc.  The platform specific
strings are not preferred in this driver.

Signed-off-by: Masahiro Yamada 
---

As an ARM-SoC developer, I only need denali.c and denali_dt.c.

I see some "Spectra:" in drivers/mtd/nand/denali_pci.c as well.
I was not quite sure if they are needed or not.
If desired, I can update this patch to remove them too.


 drivers/mtd/nand/denali.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 80d3e26..78d795b 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -402,7 +402,7 @@ static void get_hynix_nand_para(struct denali_nand_info 
*denali,
break;
default:
dev_warn(denali->dev,
-"Spectra: Unknown Hynix NAND (Device ID: 0x%x).\n"
+"Unknown Hynix NAND (Device ID: 0x%x).\n"
 "Will use default parameter values instead.\n",
 device_id);
}
@@ -1458,7 +1458,7 @@ int denali_init(struct denali_nand_info *denali)
 */
if (request_irq(denali->irq, denali_isr, IRQF_SHARED,
DENALI_NAND_NAME, denali)) {
-   pr_err("Spectra: Unable to allocate IRQ\n");
+   dev_err(denali->dev, "Unable to request IRQ\n");
return -ENODEV;
}
 
@@ -1495,7 +1495,7 @@ int denali_init(struct denali_nand_info *denali)
/* Is 32-bit DMA supported? */
ret = dma_set_mask(denali->dev, DMA_BIT_MASK(32));
if (ret) {
-   pr_err("Spectra: no usable DMA configuration\n");
+   dev_err(denali->dev, "no usable DMA configuration\n");
goto failed_req_irq;
}
 
@@ -1503,7 +1503,7 @@ int denali_init(struct denali_nand_info *denali)
 mtd->writesize + mtd->oobsize,
 DMA_BIDIRECTIONAL);
if (dma_mapping_error(denali->dev, denali->buf.dma_buf)) {
-   dev_err(denali->dev, "Spectra: failed to map DMA buffer\n");
+   dev_err(denali->dev, "failed to map DMA buffer\n");
ret = -EIO;
goto failed_req_irq;
}
@@ -1598,8 +1598,7 @@ int denali_init(struct denali_nand_info *denali)
 
ret = mtd_device_register(mtd, NULL, 0);
if (ret) {
-   dev_err(denali->dev, "Spectra: Failed to register MTD: %d\n",
-   ret);
+   dev_err(denali->dev, "Failed to register MTD: %d\n", ret);
goto failed_req_irq;
}
return 0;
-- 
1.9.1

[PATCH 06/11] mtd: nand: denali: remove unused struct member totalblks, blksperchip

[Masahiro Yamada]

The denali->blksperchip is set, but not referenced any more.  The
denali->totalblks is used only for calculating denali->blksperchip.
Both of them are unneeded.

Signed-off-by: Masahiro Yamada 
---

 drivers/mtd/nand/denali.c | 8 
 drivers/mtd/nand/denali.h | 2 --
 2 files changed, 10 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 78d795b..548278b 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -1573,14 +1573,6 @@ int denali_init(struct denali_nand_info *denali)
denali->nand.ecc.bytes *= denali->devnum;
denali->nand.ecc.strength *= denali->devnum;
 
-   /*
-* Let driver know the total blocks number and how many blocks
-* contained by each nand chip. blksperchip will help driver to
-* know how many blocks is taken by FW.
-*/
-   denali->totalblks = mtd->size >> denali->nand.phys_erase_shift;
-   denali->blksperchip = denali->totalblks / denali->nand.numchips;
-
/* override the default read operations */
denali->nand.ecc.size = ECC_SECTOR_SIZE * denali->devnum;
denali->nand.ecc.read_page = denali_read_page;
diff --git a/drivers/mtd/nand/denali.h b/drivers/mtd/nand/denali.h
index 7c0800d..ea22191 100644
--- a/drivers/mtd/nand/denali.h
+++ b/drivers/mtd/nand/denali.h
@@ -462,8 +462,6 @@ struct denali_nand_info {
int irq;
 
uint32_t devnum;/* represent how many nands connected */
-   uint32_t totalblks;
-   uint32_t blksperchip;
uint32_t bbtskipbytes;
uint32_t max_banks;
 };
-- 
1.9.1

[PATCH 08/11] mtd: nand: denali: return error code from devm_request_irq() on error

[Masahiro Yamada]

The devm_request_irq() returns an appropriate error value when it
fails.  Use it instead of the fixed -ENODEV.

While we are here, reword the comment to make it fit in a single
line, fixing the misspelling of "initialization".

Signed-off-by: Masahiro Yamada 
---

 drivers/mtd/nand/denali.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 44e075a..f188a48 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -1451,14 +1451,12 @@ int denali_init(struct denali_nand_info *denali)
denali_hw_init(denali);
denali_drv_init(denali);
 
-   /*
-* denali_isr register is done after all the hardware
-* initilization is finished
-*/
-   if (devm_request_irq(denali->dev, denali->irq, denali_isr, IRQF_SHARED,
-DENALI_NAND_NAME, denali)) {
+   /* request IRQ after all the hardware initialization is finished */
+   ret = devm_request_irq(denali->dev, denali->irq, denali_isr,
+  IRQF_SHARED, DENALI_NAND_NAME, denali);
+   if (ret) {
dev_err(denali->dev, "Unable to request IRQ\n");
-   return -ENODEV;
+   return ret;
}
 
/* now that our ISR is registered, we can enable interrupts */
-- 
1.9.1

[PATCH 10/11] mtd: nand: denali: remove unneeded parentheses

[Masahiro Yamada]

Remove parentheses surrounding the whole right side of an assignment.

Signed-off-by: Masahiro Yamada 
---

 drivers/mtd/nand/denali.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index d482d8d..14e66ab 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -1510,16 +1510,16 @@ int denali_init(struct denali_nand_info *denali)
 * the real pagesize and anything necessery
 */
denali->devnum = ioread32(denali->flash_reg + DEVICES_CONNECTED);
-   denali->nand.chipsize <<= (denali->devnum - 1);
-   denali->nand.page_shift += (denali->devnum - 1);
+   denali->nand.chipsize <<= denali->devnum - 1;
+   denali->nand.page_shift += denali->devnum - 1;
denali->nand.pagemask = (denali->nand.chipsize >>
denali->nand.page_shift) - 1;
-   denali->nand.bbt_erase_shift += (denali->devnum - 1);
+   denali->nand.bbt_erase_shift += denali->devnum - 1;
denali->nand.phys_erase_shift = denali->nand.bbt_erase_shift;
-   denali->nand.chip_shift += (denali->devnum - 1);
-   mtd->writesize <<= (denali->devnum - 1);
-   mtd->oobsize <<= (denali->devnum - 1);
-   mtd->erasesize <<= (denali->devnum - 1);
+   denali->nand.chip_shift += denali->devnum - 1;
+   mtd->writesize <<= denali->devnum - 1;
+   mtd->oobsize <<= denali->devnum - 1;
+   mtd->erasesize <<= denali->devnum - 1;
mtd->size = denali->nand.numchips * denali->nand.chipsize;
denali->bbtskipbytes *= denali->devnum;
 
-- 
1.9.1

[PATCH 09/11] mtd: nand: denali: return error code from nand_scan_ident/tail on error

[Masahiro Yamada]

The nand_scan_ident/tail() returns an appropriate error value when
it fails.  Use it instead of the fixed -ENXIO.

Signed-off-by: Masahiro Yamada 
---

 drivers/mtd/nand/denali.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index f188a48..d482d8d 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -1474,10 +1474,9 @@ int denali_init(struct denali_nand_info *denali)
 * this is the first stage in a two step process to register
 * with the nand subsystem
 */
-   if (nand_scan_ident(mtd, denali->max_banks, NULL)) {
-   ret = -ENXIO;
+   ret = nand_scan_ident(mtd, denali->max_banks, NULL);
+   if (ret)
goto failed_req_irq;
-   }
 
/* allocate the right size buffer now */
devm_kfree(denali->dev, denali->buf.buf);
@@ -1580,10 +1579,9 @@ int denali_init(struct denali_nand_info *denali)
denali->nand.ecc.write_oob = denali_write_oob;
denali->nand.erase = denali_erase;
 
-   if (nand_scan_tail(mtd)) {
-   ret = -ENXIO;
+   ret = nand_scan_tail(mtd);
+   if (ret)
goto failed_req_irq;
-   }
 
ret = mtd_device_register(mtd, NULL, 0);
if (ret) {
-- 
1.9.1

[PATCH 11/11] mtd: nand: denali: remove debug lines of __FILE__, __LINE__, __func__

[Masahiro Yamada]

Such debug lines might be useful when debugging the driver first,
but should be deleted from the upstream code.

Signed-off-by: Masahiro Yamada 
---

 drivers/mtd/nand/denali.c | 12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 14e66ab..e32e13c 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -181,9 +181,6 @@ static uint16_t denali_nand_reset(struct denali_nand_info 
*denali)
 {
int i;
 
-   dev_dbg(denali->dev, "%s, Line %d, Function: %s\n",
-   __FILE__, __LINE__, __func__);
-
for (i = 0; i < denali->max_banks; i++)
iowrite32(INTR_STATUS__RST_COMP | INTR_STATUS__TIME_OUT,
denali->flash_reg + INTR_STATUS(i));
@@ -233,9 +230,6 @@ static void nand_onfi_timing_set(struct denali_nand_info 
*denali,
uint16_t acc_clks;
uint16_t addr_2_data, re_2_we, re_2_re, we_2_re, cs_cnt;
 
-   dev_dbg(denali->dev, "%s, Line %d, Function: %s\n",
-   __FILE__, __LINE__, __func__);
-
en_lo = CEIL_DIV(Trp[mode], CLK_X);
en_hi = CEIL_DIV(Treh[mode], CLK_X);
 #if ONFI_BLOOM_TIME
@@ -480,9 +474,6 @@ static uint16_t denali_nand_timing_set(struct 
denali_nand_info *denali)
uint8_t maf_id, device_id;
int i;
 
-   dev_dbg(denali->dev, "%s, Line %d, Function: %s\n",
-   __FILE__, __LINE__, __func__);
-
/*
 * Use read id method to get device ID and other params.
 * For some NAND chips, controller can't report the correct
@@ -537,9 +528,6 @@ static uint16_t denali_nand_timing_set(struct 
denali_nand_info *denali)
 static void denali_set_intr_modes(struct denali_nand_info *denali,
uint16_t INT_ENABLE)
 {
-   dev_dbg(denali->dev, "%s, Line %d, Function: %s\n",
-   __FILE__, __LINE__, __func__);
-
if (INT_ENABLE)
iowrite32(1, denali->flash_reg + GLOBAL_INT_ENABLE);
else
-- 
1.9.1

[PATCH 08/11] mtd: nand: denali: return error code from devm_request_irq() on error

[Masahiro Yamada]

The devm_request_irq() returns an appropriate error value when it
fails.  Use it instead of the fixed -ENODEV.

While we are here, reword the comment to make it fit in a single
line, fixing the misspelling of "initialization".

Signed-off-by: Masahiro Yamada 
---

 drivers/mtd/nand/denali.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 44e075a..f188a48 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -1451,14 +1451,12 @@ int denali_init(struct denali_nand_info *denali)
denali_hw_init(denali);
denali_drv_init(denali);
 
-   /*
-* denali_isr register is done after all the hardware
-* initilization is finished
-*/
-   if (devm_request_irq(denali->dev, denali->irq, denali_isr, IRQF_SHARED,
-DENALI_NAND_NAME, denali)) {
+   /* request IRQ after all the hardware initialization is finished */
+   ret = devm_request_irq(denali->dev, denali->irq, denali_isr,
+  IRQF_SHARED, DENALI_NAND_NAME, denali);
+   if (ret) {
dev_err(denali->dev, "Unable to request IRQ\n");
-   return -ENODEV;
+   return ret;
}
 
/* now that our ISR is registered, we can enable interrupts */
-- 
1.9.1

[PATCH 10/11] mtd: nand: denali: remove unneeded parentheses

[Masahiro Yamada]

Remove parentheses surrounding the whole right side of an assignment.

Signed-off-by: Masahiro Yamada 
---

 drivers/mtd/nand/denali.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index d482d8d..14e66ab 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -1510,16 +1510,16 @@ int denali_init(struct denali_nand_info *denali)
 * the real pagesize and anything necessery
 */
denali->devnum = ioread32(denali->flash_reg + DEVICES_CONNECTED);
-   denali->nand.chipsize <<= (denali->devnum - 1);
-   denali->nand.page_shift += (denali->devnum - 1);
+   denali->nand.chipsize <<= denali->devnum - 1;
+   denali->nand.page_shift += denali->devnum - 1;
denali->nand.pagemask = (denali->nand.chipsize >>
denali->nand.page_shift) - 1;
-   denali->nand.bbt_erase_shift += (denali->devnum - 1);
+   denali->nand.bbt_erase_shift += denali->devnum - 1;
denali->nand.phys_erase_shift = denali->nand.bbt_erase_shift;
-   denali->nand.chip_shift += (denali->devnum - 1);
-   mtd->writesize <<= (denali->devnum - 1);
-   mtd->oobsize <<= (denali->devnum - 1);
-   mtd->erasesize <<= (denali->devnum - 1);
+   denali->nand.chip_shift += denali->devnum - 1;
+   mtd->writesize <<= denali->devnum - 1;
+   mtd->oobsize <<= denali->devnum - 1;
+   mtd->erasesize <<= denali->devnum - 1;
mtd->size = denali->nand.numchips * denali->nand.chipsize;
denali->bbtskipbytes *= denali->devnum;
 
-- 
1.9.1

[PATCH 09/11] mtd: nand: denali: return error code from nand_scan_ident/tail on error

[Masahiro Yamada]

The nand_scan_ident/tail() returns an appropriate error value when
it fails.  Use it instead of the fixed -ENXIO.

Signed-off-by: Masahiro Yamada 
---

 drivers/mtd/nand/denali.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index f188a48..d482d8d 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -1474,10 +1474,9 @@ int denali_init(struct denali_nand_info *denali)
 * this is the first stage in a two step process to register
 * with the nand subsystem
 */
-   if (nand_scan_ident(mtd, denali->max_banks, NULL)) {
-   ret = -ENXIO;
+   ret = nand_scan_ident(mtd, denali->max_banks, NULL);
+   if (ret)
goto failed_req_irq;
-   }
 
/* allocate the right size buffer now */
devm_kfree(denali->dev, denali->buf.buf);
@@ -1580,10 +1579,9 @@ int denali_init(struct denali_nand_info *denali)
denali->nand.ecc.write_oob = denali_write_oob;
denali->nand.erase = denali_erase;
 
-   if (nand_scan_tail(mtd)) {
-   ret = -ENXIO;
+   ret = nand_scan_tail(mtd);
+   if (ret)
goto failed_req_irq;
-   }
 
ret = mtd_device_register(mtd, NULL, 0);
if (ret) {
-- 
1.9.1

[PATCH 11/11] mtd: nand: denali: remove debug lines of __FILE__, __LINE__, __func__

[Masahiro Yamada]

Such debug lines might be useful when debugging the driver first,
but should be deleted from the upstream code.

Signed-off-by: Masahiro Yamada 
---

 drivers/mtd/nand/denali.c | 12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 14e66ab..e32e13c 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -181,9 +181,6 @@ static uint16_t denali_nand_reset(struct denali_nand_info 
*denali)
 {
int i;
 
-   dev_dbg(denali->dev, "%s, Line %d, Function: %s\n",
-   __FILE__, __LINE__, __func__);
-
for (i = 0; i < denali->max_banks; i++)
iowrite32(INTR_STATUS__RST_COMP | INTR_STATUS__TIME_OUT,
denali->flash_reg + INTR_STATUS(i));
@@ -233,9 +230,6 @@ static void nand_onfi_timing_set(struct denali_nand_info 
*denali,
uint16_t acc_clks;
uint16_t addr_2_data, re_2_we, re_2_re, we_2_re, cs_cnt;
 
-   dev_dbg(denali->dev, "%s, Line %d, Function: %s\n",
-   __FILE__, __LINE__, __func__);
-
en_lo = CEIL_DIV(Trp[mode], CLK_X);
en_hi = CEIL_DIV(Treh[mode], CLK_X);
 #if ONFI_BLOOM_TIME
@@ -480,9 +474,6 @@ static uint16_t denali_nand_timing_set(struct 
denali_nand_info *denali)
uint8_t maf_id, device_id;
int i;
 
-   dev_dbg(denali->dev, "%s, Line %d, Function: %s\n",
-   __FILE__, __LINE__, __func__);
-
/*
 * Use read id method to get device ID and other params.
 * For some NAND chips, controller can't report the correct
@@ -537,9 +528,6 @@ static uint16_t denali_nand_timing_set(struct 
denali_nand_info *denali)
 static void denali_set_intr_modes(struct denali_nand_info *denali,
uint16_t INT_ENABLE)
 {
-   dev_dbg(denali->dev, "%s, Line %d, Function: %s\n",
-   __FILE__, __LINE__, __func__);
-
if (INT_ENABLE)
iowrite32(1, denali->flash_reg + GLOBAL_INT_ENABLE);
else
-- 
1.9.1

[PATCH 07/11] mtd: nand: denali: use managed devm_irq_request()

[Masahiro Yamada]

Use the managed variant instead of request_irq() and free_irq().

Signed-off-by: Masahiro Yamada 
---

 drivers/mtd/nand/denali.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 548278b..44e075a 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -575,7 +575,6 @@ static void denali_irq_init(struct denali_nand_info *denali)
 static void denali_irq_cleanup(int irqnum, struct denali_nand_info *denali)
 {
denali_set_intr_modes(denali, false);
-   free_irq(irqnum, denali);
 }
 
 static void denali_irq_enable(struct denali_nand_info *denali,
@@ -1456,8 +1455,8 @@ int denali_init(struct denali_nand_info *denali)
 * denali_isr register is done after all the hardware
 * initilization is finished
 */
-   if (request_irq(denali->irq, denali_isr, IRQF_SHARED,
-   DENALI_NAND_NAME, denali)) {
+   if (devm_request_irq(denali->dev, denali->irq, denali_isr, IRQF_SHARED,
+DENALI_NAND_NAME, denali)) {
dev_err(denali->dev, "Unable to request IRQ\n");
return -ENODEV;
}
-- 
1.9.1

[PATCH 07/11] mtd: nand: denali: use managed devm_irq_request()

[Masahiro Yamada]

Use the managed variant instead of request_irq() and free_irq().

Signed-off-by: Masahiro Yamada 
---

 drivers/mtd/nand/denali.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 548278b..44e075a 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -575,7 +575,6 @@ static void denali_irq_init(struct denali_nand_info *denali)
 static void denali_irq_cleanup(int irqnum, struct denali_nand_info *denali)
 {
denali_set_intr_modes(denali, false);
-   free_irq(irqnum, denali);
 }
 
 static void denali_irq_enable(struct denali_nand_info *denali,
@@ -1456,8 +1455,8 @@ int denali_init(struct denali_nand_info *denali)
 * denali_isr register is done after all the hardware
 * initilization is finished
 */
-   if (request_irq(denali->irq, denali_isr, IRQF_SHARED,
-   DENALI_NAND_NAME, denali)) {
+   if (devm_request_irq(denali->dev, denali->irq, denali_isr, IRQF_SHARED,
+DENALI_NAND_NAME, denali)) {
dev_err(denali->dev, "Unable to request IRQ\n");
return -ENODEV;
}
-- 
1.9.1

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Ricardo Neri]

On Tue, 2016-11-08 at 07:34 -0800, Andy Lutomirski wrote:
> > Would it not be better to emulate these instructions for them? What
> way
> > we can verify they're not malicious.
> 
> Forget malice -- if they are really needed for some silly vm86-using
> program, let's trap them and emulate them so they return dummy values.
> 
> Also, keep in mind that vm86 is already effectively gated behind a
> sysctl for non-root.  I think the default should be that, if root has
> enabled vm86, it should work.

Then should I keep UMIP enabled by default and still provide an option
to disable it via a kernel parameter?

Also, a third option, umip=novm86 would "disable" UMIP in vm86 tasks.
Under the new approach (of emulating the impacted instructions), this
option, a #GP fault would still be generated but the actual values of
GDT/LDT/IDT/MSW would be passed to user space. Does this make sense?

Thanks and BR,
Ricardo

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Ricardo Neri]

On Tue, 2016-11-08 at 07:34 -0800, Andy Lutomirski wrote:
> > Would it not be better to emulate these instructions for them? What
> way
> > we can verify they're not malicious.
> 
> Forget malice -- if they are really needed for some silly vm86-using
> program, let's trap them and emulate them so they return dummy values.
> 
> Also, keep in mind that vm86 is already effectively gated behind a
> sysctl for non-root.  I think the default should be that, if root has
> enabled vm86, it should work.

Then should I keep UMIP enabled by default and still provide an option
to disable it via a kernel parameter?

Also, a third option, umip=novm86 would "disable" UMIP in vm86 tasks.
Under the new approach (of emulating the impacted instructions), this
option, a #GP fault would still be generated but the actual values of
GDT/LDT/IDT/MSW would be passed to user space. Does this make sense?

Thanks and BR,
Ricardo

Re: [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver

[Anurup M]

On Tuesday 08 November 2016 08:38 PM, Arnd Bergmann wrote:

On Tuesday, November 8, 2016 7:16:30 PM CET Anurup M wrote:

If these are backwards compatible, just mark them as compatible in DT,
e.g. hip06 can use

compatible = "hisilicon,hip06-cpu-djtag-v1", "hisilicon,hip05-cpu-djtag-v1";

so you can tell the difference if you need to, but the driver only has to
list the oldest one here.

What is the difference between the cpu and io djtag interfaces?

On some chips like hip06, the djtag version is different for IO die.

In what way? The driver doesn't seem to care about the difference.

There is  a difference in djtag version of CPU and IO die (in some chips).
For ex: in hip06 djtag for CPU is v1 and for IO is v2.
so they use different readwrite handlers djtag_readwrite_(v1/2).

+   /* for hip06(D03) cpu die */
+   { .compatible = "hisilicon,hip06-cpu-djtag-v1",
+   .data = (void *)djtag_readwrite_v1 },
+   /* for hip06(D03) io die */
+   { .compatible = "hisilicon,hip06-io-djtag-v2",
+   .data = (void *)djtag_readwrite_v2 },


For the same djtag version, there is no difference in handling in the
driver.

Right, but my point was about the compatibility with the older chips
using the same IP block, marking the ones as compatible that actually
use the same interface.

I also see that the compatible strings have the version included in
them, and you can probably drop them by requiring them only in the
fallback:

compatible = "hisilicon,hip05-cpu-djtag", "hisilicon,djtag-v1";
compatible = "hisilicon,hip05-io-djtag", "hisilicon,djtag-v1";
compatible = "hisilicon,hip06-cpu-djtag", "hisilicon,djtag-v1";
compatible = "hisilicon,hip06-io-djtag", "hisilicon,djtag-v2";
compatible = "hisilicon,hip07-cpu-djtag", "hisilicon,djtag-v2";
compatible = "hisilicon,hip07-io-djtag", "hisilicon,djtag-v2";

We want to have the first entry be as specific as possible, but
the last (second) entry is the one that can be used by the driver
for matching. When a future hip08/hip09/... chip uses an existing
interface, you then don't have to update the driver.
Thanks. I had a similar thought on this. So as I have the version string 
in the

second entry "-v(1/2)".
I can use it in driver for matching. So i think  I will change it as below.
Please correct me if my understanding is wrong.

 static const struct of_device_id djtag_of_match[] = {
-   /* for hip05(D02) cpu die */
-   { .compatible = "hisilicon,hip05-cpu-djtag-v1",
+   /* for hisi djtag-v1 cpu die */
+   { .compatible = "hisilicon,hisi-cpu-djtag-v1",
.data = djtag_readwrite_v1 },
-   /* for hip05(D02) io die */
-   { .compatible = "hisilicon,hip05-io-djtag-v1",
+   /* for hisi djtag-v1 io die */
+   { .compatible = "hisilicon,hisi-io-djtag-v1",
.data = djtag_readwrite_v1 },
-   /* for hip06(D03) cpu die */
-   { .compatible = "hisilicon,hip06-cpu-djtag-v1",
-   .data = djtag_readwrite_v1 },
-   /* for hip06(D03) io die */
-   { .compatible = "hisilicon,hip06-io-djtag-v2",
-   .data = djtag_readwrite_v2 },
-   /* for hip07(D05) cpu die */
-   { .compatible = "hisilicon,hip07-cpu-djtag-v2",
+   /* for hisi djtag-v2 cpu die */
+   { .compatible = "hisilicon,hisi-cpu-djtag-v2",
.data = djtag_readwrite_v2 },
-   /* for hip07(D05) io die */
-   { .compatible = "hisilicon,hip07-io-djtag-v2",
+   /* for hisi djtag-v2 io die */
+   { .compatible = "hisilicon,hisi-io-djtag-v2",
.data = (djtag_readwrite_v2 },
{},
 };

Thanks,
Anurup

Arnd

Re: [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver

[Anurup M]

On Tuesday 08 November 2016 08:38 PM, Arnd Bergmann wrote:

On Tuesday, November 8, 2016 7:16:30 PM CET Anurup M wrote:

If these are backwards compatible, just mark them as compatible in DT,
e.g. hip06 can use

compatible = "hisilicon,hip06-cpu-djtag-v1", "hisilicon,hip05-cpu-djtag-v1";

so you can tell the difference if you need to, but the driver only has to
list the oldest one here.

What is the difference between the cpu and io djtag interfaces?

On some chips like hip06, the djtag version is different for IO die.

In what way? The driver doesn't seem to care about the difference.

There is  a difference in djtag version of CPU and IO die (in some chips).
For ex: in hip06 djtag for CPU is v1 and for IO is v2.
so they use different readwrite handlers djtag_readwrite_(v1/2).

+   /* for hip06(D03) cpu die */
+   { .compatible = "hisilicon,hip06-cpu-djtag-v1",
+   .data = (void *)djtag_readwrite_v1 },
+   /* for hip06(D03) io die */
+   { .compatible = "hisilicon,hip06-io-djtag-v2",
+   .data = (void *)djtag_readwrite_v2 },


For the same djtag version, there is no difference in handling in the
driver.

Right, but my point was about the compatibility with the older chips
using the same IP block, marking the ones as compatible that actually
use the same interface.

I also see that the compatible strings have the version included in
them, and you can probably drop them by requiring them only in the
fallback:

compatible = "hisilicon,hip05-cpu-djtag", "hisilicon,djtag-v1";
compatible = "hisilicon,hip05-io-djtag", "hisilicon,djtag-v1";
compatible = "hisilicon,hip06-cpu-djtag", "hisilicon,djtag-v1";
compatible = "hisilicon,hip06-io-djtag", "hisilicon,djtag-v2";
compatible = "hisilicon,hip07-cpu-djtag", "hisilicon,djtag-v2";
compatible = "hisilicon,hip07-io-djtag", "hisilicon,djtag-v2";

We want to have the first entry be as specific as possible, but
the last (second) entry is the one that can be used by the driver
for matching. When a future hip08/hip09/... chip uses an existing
interface, you then don't have to update the driver.
Thanks. I had a similar thought on this. So as I have the version string 
in the

second entry "-v(1/2)".
I can use it in driver for matching. So i think  I will change it as below.
Please correct me if my understanding is wrong.

 static const struct of_device_id djtag_of_match[] = {
-   /* for hip05(D02) cpu die */
-   { .compatible = "hisilicon,hip05-cpu-djtag-v1",
+   /* for hisi djtag-v1 cpu die */
+   { .compatible = "hisilicon,hisi-cpu-djtag-v1",
.data = djtag_readwrite_v1 },
-   /* for hip05(D02) io die */
-   { .compatible = "hisilicon,hip05-io-djtag-v1",
+   /* for hisi djtag-v1 io die */
+   { .compatible = "hisilicon,hisi-io-djtag-v1",
.data = djtag_readwrite_v1 },
-   /* for hip06(D03) cpu die */
-   { .compatible = "hisilicon,hip06-cpu-djtag-v1",
-   .data = djtag_readwrite_v1 },
-   /* for hip06(D03) io die */
-   { .compatible = "hisilicon,hip06-io-djtag-v2",
-   .data = djtag_readwrite_v2 },
-   /* for hip07(D05) cpu die */
-   { .compatible = "hisilicon,hip07-cpu-djtag-v2",
+   /* for hisi djtag-v2 cpu die */
+   { .compatible = "hisilicon,hisi-cpu-djtag-v2",
.data = djtag_readwrite_v2 },
-   /* for hip07(D05) io die */
-   { .compatible = "hisilicon,hip07-io-djtag-v2",
+   /* for hisi djtag-v2 io die */
+   { .compatible = "hisilicon,hisi-io-djtag-v2",
.data = (djtag_readwrite_v2 },
{},
 };

Thanks,
Anurup

Arnd

Re: [PATCH 2/4] x86: Prepare vm86 tasks to handle User-Mode Instruction Prevention

[Ricardo Neri]

On Tue, 2016-11-08 at 18:00 +0100, Peter Zijlstra wrote:
> > > +   }
> > > +#endif
> > > +
> > 
> > NAK.  If this code is going to exist, it needs to be deeply buried
> in
> > some unlikely if statement that already exists.  There's no good
> > reason to penalize all context switches to support some nonsensical
> > vm86 use case.
> 
> Agreed, now if instead vm86 get to emulate these instructions, this
> all
> magically goes away..

Yes. I agree. I will rework the series and this should not be needed.

Thanks and BR,
Ricardo

Re: [PATCH 2/4] x86: Prepare vm86 tasks to handle User-Mode Instruction Prevention

[Ricardo Neri]

On Tue, 2016-11-08 at 18:00 +0100, Peter Zijlstra wrote:
> > > +   }
> > > +#endif
> > > +
> > 
> > NAK.  If this code is going to exist, it needs to be deeply buried
> in
> > some unlikely if statement that already exists.  There's no good
> > reason to penalize all context switches to support some nonsensical
> > vm86 use case.
> 
> Agreed, now if instead vm86 get to emulate these instructions, this
> all
> magically goes away..

Yes. I agree. I will rework the series and this should not be needed.

Thanks and BR,
Ricardo