Re: [PATCH v2] OMAPDSS: HDMI5: Change DDC timings

[Tomi Valkeinen]

On 21/04/16 20:27, J.D. Schroeder wrote:
> From: Jim Lodes 
> 
> The DDC scl high and low times were set to the minimum values
> from the i2c specification, but the i2c specification takes into
> account the rise time and fall time to calculate the frequency.
> To pass HDMI certification DDC can not exceed 100kHz therefore in
> a system where the rise times and fall times are negligible the high
> and low times for scl need to be 10us.
> 
> Signed-off-by: Jim Lodes 
> Signed-off-by: J.D. Schroeder 
> ---
>  drivers/gpu/drm/omapdrm/dss/hdmi5_core.c  | 4 ++--
>  drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)

Thanks! Queuing this for 4.7.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v2] OMAPDSS: HDMI5: Change DDC timings

[Tomi Valkeinen]

On 21/04/16 20:27, J.D. Schroeder wrote:
> From: Jim Lodes 
> 
> The DDC scl high and low times were set to the minimum values
> from the i2c specification, but the i2c specification takes into
> account the rise time and fall time to calculate the frequency.
> To pass HDMI certification DDC can not exceed 100kHz therefore in
> a system where the rise times and fall times are negligible the high
> and low times for scl need to be 10us.
> 
> Signed-off-by: Jim Lodes 
> Signed-off-by: J.D. Schroeder 
> ---
>  drivers/gpu/drm/omapdrm/dss/hdmi5_core.c  | 4 ++--
>  drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)

Thanks! Queuing this for 4.7.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v2] OMAPDSS: HDMI5: Fix AVI infoframe

[Tomi Valkeinen]

On 21/04/16 20:49, J.D. Schroeder wrote:
> From: Jim Lodes 
> 
> The AVI infoframe R0-R3 in the 2nd data byte represents the
> Active Format Aspect Ratio. It is four bits long not two bits.
> This fixes that mask used to extract the bits before writing the
> bits to the hardware registers.
> 
> Signed-off-by: Jim Lodes 
> Signed-off-by: J.D. Schroeder 
> ---
>  drivers/gpu/drm/omapdrm/dss/hdmi5_core.c  | 2 +-
>  drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

Thanks! Queuing this for 4.7.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v2] OMAPDSS: HDMI5: Fix AVI infoframe

[Tomi Valkeinen]

On 21/04/16 20:49, J.D. Schroeder wrote:
> From: Jim Lodes 
> 
> The AVI infoframe R0-R3 in the 2nd data byte represents the
> Active Format Aspect Ratio. It is four bits long not two bits.
> This fixes that mask used to extract the bits before writing the
> bits to the hardware registers.
> 
> Signed-off-by: Jim Lodes 
> Signed-off-by: J.D. Schroeder 
> ---
>  drivers/gpu/drm/omapdrm/dss/hdmi5_core.c  | 2 +-
>  drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

Thanks! Queuing this for 4.7.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [RESEND PATCH v2 1/7] usb: xhci: plat: Fix suspend/resume when the optional clk exists

[Jisheng Zhang]

Dear Felipe,

On Wed, 27 Apr 2016 08:25:38 +0300 Felipe Balbi wrote:

> Hi,
> 
> (since you're fixing somebody else's commit, it's nice to Cc authors)
> 
> Jisheng Zhang  writes:
> > Commit 4718c1774051 ("usb: host: xhci-plat: add clock support") adds
> > optional clk support, but it forgets to prepare/disable and  
>   ^^^
>   prepare/enable ?
> 
> > enable/unprepare the clk in the resume/suspend path. This path fixes  
>     
>   disable/unprepare ?   patch
> 
> > this issue by adding missing clk related calls.  
> 
> frankly, I'm not sure this patch is entirely correct. At minimum, it's
> not necessarily a bug fix. Original commit had no intent in gating
> clocks during suspend/resume and, IMHO, that might not be what *all*
> XHCI implementations want, though I'm not entirely sure.

Thanks for the hint. Indeed, that's not all xhci-plat users want. I'll drop
this patch in v3.

Thanks a lot for the review,
Jisheng

> 
> > Signed-off-by: Jisheng Zhang 
> > Fixes: 4718c1774051 ("usb: host: xhci-plat: add clock support")  
> 
> Assuming this is, indeed, a fix; you need to Cc stable here. Just add:
> 
> Cc:  # v3.16+
> 
> > ---
> >  drivers/usb/host/xhci-plat.c | 14 +-
> >  1 file changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> > index 474b5fa..8cb46cb 100644
> > --- a/drivers/usb/host/xhci-plat.c
> > +++ b/drivers/usb/host/xhci-plat.c
> > @@ -295,6 +295,7 @@ static int xhci_plat_remove(struct platform_device *dev)
> >  #ifdef CONFIG_PM_SLEEP
> >  static int xhci_plat_suspend(struct device *dev)
> >  {
> > +   int ret;  
> 
> this would look neater after hcd and xhci declarations below
> 
> > struct usb_hcd  *hcd = dev_get_drvdata(dev);
> > struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> >  
> > @@ -306,14 +307,25 @@ static int xhci_plat_suspend(struct device *dev)
> >  * reconsider this when xhci_plat_suspend enlarges its scope, e.g.,
> >  * also applies to runtime suspend.
> >  */
> > -   return xhci_suspend(xhci, device_may_wakeup(dev));
> > +   ret = xhci_suspend(xhci, device_may_wakeup(dev));
> > +   if (ret)
> > +   return ret;
> > +
> > +   clk_disable_unprepare(xhci->clk);
> > +
> > +   return ret;
> >  }
> >  
> >  static int xhci_plat_resume(struct device *dev)
> >  {
> > +   int ret;  
> 
> ditto
> 
> > struct usb_hcd  *hcd = dev_get_drvdata(dev);
> > struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> >  
> > +   ret = clk_prepare_enable(xhci->clk);
> > +   if (ret)
> > +   return ret;
> > +
> > return xhci_resume(xhci, 0);
> >  }
> >  
> > -- 
> > 2.8.1
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html  
> 

Re: [RESEND PATCH v2 1/7] usb: xhci: plat: Fix suspend/resume when the optional clk exists

[Jisheng Zhang]

Dear Felipe,

On Wed, 27 Apr 2016 08:25:38 +0300 Felipe Balbi wrote:

> Hi,
> 
> (since you're fixing somebody else's commit, it's nice to Cc authors)
> 
> Jisheng Zhang  writes:
> > Commit 4718c1774051 ("usb: host: xhci-plat: add clock support") adds
> > optional clk support, but it forgets to prepare/disable and  
>   ^^^
>   prepare/enable ?
> 
> > enable/unprepare the clk in the resume/suspend path. This path fixes  
>     
>   disable/unprepare ?   patch
> 
> > this issue by adding missing clk related calls.  
> 
> frankly, I'm not sure this patch is entirely correct. At minimum, it's
> not necessarily a bug fix. Original commit had no intent in gating
> clocks during suspend/resume and, IMHO, that might not be what *all*
> XHCI implementations want, though I'm not entirely sure.

Thanks for the hint. Indeed, that's not all xhci-plat users want. I'll drop
this patch in v3.

Thanks a lot for the review,
Jisheng

> 
> > Signed-off-by: Jisheng Zhang 
> > Fixes: 4718c1774051 ("usb: host: xhci-plat: add clock support")  
> 
> Assuming this is, indeed, a fix; you need to Cc stable here. Just add:
> 
> Cc:  # v3.16+
> 
> > ---
> >  drivers/usb/host/xhci-plat.c | 14 +-
> >  1 file changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> > index 474b5fa..8cb46cb 100644
> > --- a/drivers/usb/host/xhci-plat.c
> > +++ b/drivers/usb/host/xhci-plat.c
> > @@ -295,6 +295,7 @@ static int xhci_plat_remove(struct platform_device *dev)
> >  #ifdef CONFIG_PM_SLEEP
> >  static int xhci_plat_suspend(struct device *dev)
> >  {
> > +   int ret;  
> 
> this would look neater after hcd and xhci declarations below
> 
> > struct usb_hcd  *hcd = dev_get_drvdata(dev);
> > struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> >  
> > @@ -306,14 +307,25 @@ static int xhci_plat_suspend(struct device *dev)
> >  * reconsider this when xhci_plat_suspend enlarges its scope, e.g.,
> >  * also applies to runtime suspend.
> >  */
> > -   return xhci_suspend(xhci, device_may_wakeup(dev));
> > +   ret = xhci_suspend(xhci, device_may_wakeup(dev));
> > +   if (ret)
> > +   return ret;
> > +
> > +   clk_disable_unprepare(xhci->clk);
> > +
> > +   return ret;
> >  }
> >  
> >  static int xhci_plat_resume(struct device *dev)
> >  {
> > +   int ret;  
> 
> ditto
> 
> > struct usb_hcd  *hcd = dev_get_drvdata(dev);
> > struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> >  
> > +   ret = clk_prepare_enable(xhci->clk);
> > +   if (ret)
> > +   return ret;
> > +
> > return xhci_resume(xhci, 0);
> >  }
> >  
> > -- 
> > 2.8.1
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html  
> 

Re: [PATCH 1/1] [RFC] workqueue: fix ghost PENDING flag while doing MQ IO

[Hannes Reinecke]

On 04/26/2016 07:45 PM, Tejun Heo wrote:
> Hello, Peter.
> 
> On Tue, Apr 26, 2016 at 10:27:59AM -0700, Peter Hurley wrote:
>>> It's unlikely to make any measureable difference.  Is xchg() actually
>>> cheaper than store + rmb?
>>
>> store + mfence (full barrier), yes. Roughly 2x faster.
>>
>> https://lkml.org/lkml/2015/11/2/607
> 
> Ah, didn't know that.  Thanks for the pointer.
> 
>>> I'm not necessarily against making all clearings of
>>> PENDING to be followed by a rmb or use xhcg.  Reasons 2-4 are pretty
>>> weak tho.
>>
>> I agree 2 and 3 are not the best reasons.
>> Actually, it looks that I'm in the minority anyway, and that style-wise,
>> naked barrier is preferred.
> 
> As long as what's happening is clearly documented, I think either is
> fine.  I'm gonna go with Roman's mb patch for -stable fix but think
> it'd be nice to have a separate patch to consolidate the paths which
> clear PENDING and make them use xchg.  If you can spin up a patch for
> that, I'd be happy to apply it to wq/for-3.7.
>  ^^^
Ah. Time warp.
I knew it would happen eventually :-)

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/1] [RFC] workqueue: fix ghost PENDING flag while doing MQ IO

[Hannes Reinecke]

On 04/26/2016 07:45 PM, Tejun Heo wrote:
> Hello, Peter.
> 
> On Tue, Apr 26, 2016 at 10:27:59AM -0700, Peter Hurley wrote:
>>> It's unlikely to make any measureable difference.  Is xchg() actually
>>> cheaper than store + rmb?
>>
>> store + mfence (full barrier), yes. Roughly 2x faster.
>>
>> https://lkml.org/lkml/2015/11/2/607
> 
> Ah, didn't know that.  Thanks for the pointer.
> 
>>> I'm not necessarily against making all clearings of
>>> PENDING to be followed by a rmb or use xhcg.  Reasons 2-4 are pretty
>>> weak tho.
>>
>> I agree 2 and 3 are not the best reasons.
>> Actually, it looks that I'm in the minority anyway, and that style-wise,
>> naked barrier is preferred.
> 
> As long as what's happening is clearly documented, I think either is
> fine.  I'm gonna go with Roman's mb patch for -stable fix but think
> it'd be nice to have a separate patch to consolidate the paths which
> clear PENDING and make them use xchg.  If you can spin up a patch for
> that, I'd be happy to apply it to wq/for-3.7.
>  ^^^
Ah. Time warp.
I knew it would happen eventually :-)

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)

[PATCH v2] net: Add Qualcomm IPC router

[Bjorn Andersson]

From: Courtney Cavin 

Add an implementation of Qualcomm's IPC router protocol, used to
communicate with service providing remote processors.

Signed-off-by: Courtney Cavin 
Signed-off-by: Bjorn Andersson 
[bjorn: Cope with 0 being a valid node id and implement RTM_NEWADDR]
Signed-off-by: Bjorn Andersson 
---

Changes since v1:
- Made node 0 (normally the Qualcomm modem) a valid node
- Implemented RTM_NEWADDR for specifying the local node id

 include/linux/socket.h|4 +-
 include/uapi/linux/qrtr.h |   12 +
 net/Kconfig   |1 +
 net/Makefile  |1 +
 net/qrtr/Kconfig  |   24 ++
 net/qrtr/Makefile |2 +
 net/qrtr/qrtr.c   | 1007 +
 net/qrtr/qrtr.h   |   31 ++
 net/qrtr/smd.c|  117 ++
 9 files changed, 1198 insertions(+), 1 deletion(-)
 create mode 100644 include/uapi/linux/qrtr.h
 create mode 100644 net/qrtr/Kconfig
 create mode 100644 net/qrtr/Makefile
 create mode 100644 net/qrtr/qrtr.c
 create mode 100644 net/qrtr/qrtr.h
 create mode 100644 net/qrtr/smd.c

diff --git a/include/linux/socket.h b/include/linux/socket.h
index 73bf6c6a833b..b5cc5a6d7011 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -201,8 +201,9 @@ struct ucred {
 #define AF_NFC 39  /* NFC sockets  */
 #define AF_VSOCK   40  /* vSockets */
 #define AF_KCM 41  /* Kernel Connection Multiplexor*/
+#define AF_QIPCRTR 42  /* Qualcomm IPC Router  */
 
-#define AF_MAX 42  /* For now.. */
+#define AF_MAX 43  /* For now.. */
 
 /* Protocol families, same as address families. */
 #define PF_UNSPEC  AF_UNSPEC
@@ -249,6 +250,7 @@ struct ucred {
 #define PF_NFC AF_NFC
 #define PF_VSOCK   AF_VSOCK
 #define PF_KCM AF_KCM
+#define PF_QIPCRTR AF_QIPCRTR
 #define PF_MAX AF_MAX
 
 /* Maximum queue length specifiable by listen.  */
diff --git a/include/uapi/linux/qrtr.h b/include/uapi/linux/qrtr.h
new file mode 100644
index ..66c0748d26e2
--- /dev/null
+++ b/include/uapi/linux/qrtr.h
@@ -0,0 +1,12 @@
+#ifndef _LINUX_QRTR_H
+#define _LINUX_QRTR_H
+
+#include 
+
+struct sockaddr_qrtr {
+   __kernel_sa_family_t sq_family;
+   __u32 sq_node;
+   __u32 sq_port;
+};
+
+#endif /* _LINUX_QRTR_H */
diff --git a/net/Kconfig b/net/Kconfig
index a8934d8c8fda..b841c42e5c9b 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -236,6 +236,7 @@ source "net/mpls/Kconfig"
 source "net/hsr/Kconfig"
 source "net/switchdev/Kconfig"
 source "net/l3mdev/Kconfig"
+source "net/qrtr/Kconfig"
 
 config RPS
bool
diff --git a/net/Makefile b/net/Makefile
index 81d14119eab5..bdd14553a774 100644
--- a/net/Makefile
+++ b/net/Makefile
@@ -78,3 +78,4 @@ endif
 ifneq ($(CONFIG_NET_L3_MASTER_DEV),)
 obj-y  += l3mdev/
 endif
+obj-$(CONFIG_QRTR) += qrtr/
diff --git a/net/qrtr/Kconfig b/net/qrtr/Kconfig
new file mode 100644
index ..f053cc25f621
--- /dev/null
+++ b/net/qrtr/Kconfig
@@ -0,0 +1,24 @@
+# Qualcomm IPC Router configuration
+#
+
+config QRTR
+   bool "Qualcomm IPC Router support"
+   depends on ARCH_QCOM || COMPILE_TEST
+   ---help---
+ Say Y if you intend to use Qualcomm IPC router protocol.  The
+ protocol is used to communicate with services provided by other
+ hardware blocks in the system.
+
+ In order to do service lookups, a userspace daemon is required to
+ maintain a service listing.
+
+if QRTR
+
+config QRTR_SMD
+   tristate "SMD IPC Router channels"
+   depends on QRTR && QCOM_SMD && OF
+   ---help---
+ Say Y here to support SMD based ipcrouter channels.  SMD is the
+ most common transport for IPC Router.
+
+endif # QRTR
diff --git a/net/qrtr/Makefile b/net/qrtr/Makefile
new file mode 100644
index ..e282a84ffc5c
--- /dev/null
+++ b/net/qrtr/Makefile
@@ -0,0 +1,2 @@
+obj-y := qrtr.o
+obj-$(CONFIG_QRTR_SMD) += smd.o
diff --git a/net/qrtr/qrtr.c b/net/qrtr/qrtr.c
new file mode 100644
index ..c985ecbe9bd6
--- /dev/null
+++ b/net/qrtr/qrtr.c
@@ -0,0 +1,1007 @@
+/*
+ * Copyright (c) 2015, Sony Mobile Communications Inc.
+ * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include  /* 

[PATCH v2] net: Add Qualcomm IPC router

[Bjorn Andersson]

From: Courtney Cavin 

Add an implementation of Qualcomm's IPC router protocol, used to
communicate with service providing remote processors.

Signed-off-by: Courtney Cavin 
Signed-off-by: Bjorn Andersson 
[bjorn: Cope with 0 being a valid node id and implement RTM_NEWADDR]
Signed-off-by: Bjorn Andersson 
---

Changes since v1:
- Made node 0 (normally the Qualcomm modem) a valid node
- Implemented RTM_NEWADDR for specifying the local node id

 include/linux/socket.h|4 +-
 include/uapi/linux/qrtr.h |   12 +
 net/Kconfig   |1 +
 net/Makefile  |1 +
 net/qrtr/Kconfig  |   24 ++
 net/qrtr/Makefile |2 +
 net/qrtr/qrtr.c   | 1007 +
 net/qrtr/qrtr.h   |   31 ++
 net/qrtr/smd.c|  117 ++
 9 files changed, 1198 insertions(+), 1 deletion(-)
 create mode 100644 include/uapi/linux/qrtr.h
 create mode 100644 net/qrtr/Kconfig
 create mode 100644 net/qrtr/Makefile
 create mode 100644 net/qrtr/qrtr.c
 create mode 100644 net/qrtr/qrtr.h
 create mode 100644 net/qrtr/smd.c

diff --git a/include/linux/socket.h b/include/linux/socket.h
index 73bf6c6a833b..b5cc5a6d7011 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -201,8 +201,9 @@ struct ucred {
 #define AF_NFC 39  /* NFC sockets  */
 #define AF_VSOCK   40  /* vSockets */
 #define AF_KCM 41  /* Kernel Connection Multiplexor*/
+#define AF_QIPCRTR 42  /* Qualcomm IPC Router  */
 
-#define AF_MAX 42  /* For now.. */
+#define AF_MAX 43  /* For now.. */
 
 /* Protocol families, same as address families. */
 #define PF_UNSPEC  AF_UNSPEC
@@ -249,6 +250,7 @@ struct ucred {
 #define PF_NFC AF_NFC
 #define PF_VSOCK   AF_VSOCK
 #define PF_KCM AF_KCM
+#define PF_QIPCRTR AF_QIPCRTR
 #define PF_MAX AF_MAX
 
 /* Maximum queue length specifiable by listen.  */
diff --git a/include/uapi/linux/qrtr.h b/include/uapi/linux/qrtr.h
new file mode 100644
index ..66c0748d26e2
--- /dev/null
+++ b/include/uapi/linux/qrtr.h
@@ -0,0 +1,12 @@
+#ifndef _LINUX_QRTR_H
+#define _LINUX_QRTR_H
+
+#include 
+
+struct sockaddr_qrtr {
+   __kernel_sa_family_t sq_family;
+   __u32 sq_node;
+   __u32 sq_port;
+};
+
+#endif /* _LINUX_QRTR_H */
diff --git a/net/Kconfig b/net/Kconfig
index a8934d8c8fda..b841c42e5c9b 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -236,6 +236,7 @@ source "net/mpls/Kconfig"
 source "net/hsr/Kconfig"
 source "net/switchdev/Kconfig"
 source "net/l3mdev/Kconfig"
+source "net/qrtr/Kconfig"
 
 config RPS
bool
diff --git a/net/Makefile b/net/Makefile
index 81d14119eab5..bdd14553a774 100644
--- a/net/Makefile
+++ b/net/Makefile
@@ -78,3 +78,4 @@ endif
 ifneq ($(CONFIG_NET_L3_MASTER_DEV),)
 obj-y  += l3mdev/
 endif
+obj-$(CONFIG_QRTR) += qrtr/
diff --git a/net/qrtr/Kconfig b/net/qrtr/Kconfig
new file mode 100644
index ..f053cc25f621
--- /dev/null
+++ b/net/qrtr/Kconfig
@@ -0,0 +1,24 @@
+# Qualcomm IPC Router configuration
+#
+
+config QRTR
+   bool "Qualcomm IPC Router support"
+   depends on ARCH_QCOM || COMPILE_TEST
+   ---help---
+ Say Y if you intend to use Qualcomm IPC router protocol.  The
+ protocol is used to communicate with services provided by other
+ hardware blocks in the system.
+
+ In order to do service lookups, a userspace daemon is required to
+ maintain a service listing.
+
+if QRTR
+
+config QRTR_SMD
+   tristate "SMD IPC Router channels"
+   depends on QRTR && QCOM_SMD && OF
+   ---help---
+ Say Y here to support SMD based ipcrouter channels.  SMD is the
+ most common transport for IPC Router.
+
+endif # QRTR
diff --git a/net/qrtr/Makefile b/net/qrtr/Makefile
new file mode 100644
index ..e282a84ffc5c
--- /dev/null
+++ b/net/qrtr/Makefile
@@ -0,0 +1,2 @@
+obj-y := qrtr.o
+obj-$(CONFIG_QRTR_SMD) += smd.o
diff --git a/net/qrtr/qrtr.c b/net/qrtr/qrtr.c
new file mode 100644
index ..c985ecbe9bd6
--- /dev/null
+++ b/net/qrtr/qrtr.c
@@ -0,0 +1,1007 @@
+/*
+ * Copyright (c) 2015, Sony Mobile Communications Inc.
+ * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include  /* For TIOCINQ/OUTQ */
+
+#include 
+
+#include "qrtr.h"
+
+#define QRTR_PROTO_VER 1
+
+/* auto-bind range */
+#define 

Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

[Felipe Balbi]

Hi,

Grygorii Strashko  writes:
> On 04/26/2016 09:17 AM, Felipe Balbi wrote:
>> 
>> Hi,
>> 
>> Grygorii Strashko  writes:
>>> Now not all DMA paremters configured properly for "xhci-hcd" platform
>>> device which is created manually. For example: dma_pfn_offset, dam_ops
>>> and iommu configuration will not corresponds "dwc3" devices
>>> configuration. As result, this will cause problems like wrong DMA
>>> addresses translation on platforms with LPAE enabled like Keystone 2.
>>>
>>> When platform is using DT boot mode the DMA configuration will be
>>> parsed and applied from DT, so, to fix this issue, reuse
>>> of_dma_configure() API and retrieve DMA configuartion for "xhci-hcd"
>>> from DWC3 device node.
>> 
>> patch is incomplete. You left out non-DT users which might suffer from
>> the same problem.
>> 
>
> Honestly, I don't know how to fix it gracefully for non-DT case.
> I can update commit message to mention that this is fix for DT case only.

no, that won't do :-) There are other users for this driver and they are
all "out-of-compliance" when it comes to DMA usage. Apparently, the
desired behavior is to pass correct device to DMA API which the gadget
side is already doing (see below). For the host side, the fix has to be
more involved.

Frankly, I'd prefer that DMA setup could be inherited from parent
device, then it wouldn't really matter and a bunch of this could be
simplified. Some sort of dma_inherit(struct device *dev, struct device
*parent) would go a long way, IMHO.

8< cut here 
commit 2725d6f974c4c268ae5fb746f8e3b33b76135aa8
Author: Felipe Balbi 
Date:   Tue Apr 19 16:18:12 2016 +0300

usb: dwc3: use parent device for DMA

our parent device is the one which was initialized
by either PCI or DeviceTree and that's the one which
is configured properly for DMA access.

Instead of copying DMA bits from parent to child,
let's just rely on parent device for the entire DMA
API.

Signed-off-by: Felipe Balbi 

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index c050a88c16d4..09e4ff71a50f 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -180,7 +180,7 @@ static void dwc3_frame_length_adjustment(struct dwc3 *dwc, 
u32 fladj)
 static void dwc3_free_one_event_buffer(struct dwc3 *dwc,
struct dwc3_event_buffer *evt)
 {
-   dma_free_coherent(dwc->dev, evt->length, evt->buf, evt->dma);
+   dma_free_coherent(dwc->dev->parent, evt->length, evt->buf, evt->dma);
 }
 
 /**
@@ -202,7 +202,7 @@ static struct dwc3_event_buffer 
*dwc3_alloc_one_event_buffer(struct dwc3 *dwc,
 
evt->dwc= dwc;
evt->length = length;
-   evt->buf= dma_alloc_coherent(dwc->dev, length,
+   evt->buf= dma_alloc_coherent(dwc->dev->parent, length,
>dma, GFP_KERNEL);
if (!evt->buf)
return ERR_PTR(-ENOMEM);
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 143deb420481..c78238dc76fc 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -967,7 +967,7 @@ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc,
u32 transfer_size = 0;
u32 maxpacket;
 
-   ret = usb_gadget_map_request(>gadget, >request,
+   ret = usb_gadget_map_request_by_dev(dwc->dev->parent, 
>request,
dep->number);
if (ret) {
dwc3_trace(trace_dwc3_ep0, "failed to map request\n");
@@ -995,7 +995,7 @@ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc,
dwc->ep0_bounce_addr, transfer_size,
DWC3_TRBCTL_CONTROL_DATA, false);
} else {
-   ret = usb_gadget_map_request(>gadget, >request,
+   ret = usb_gadget_map_request_by_dev(dwc->dev->parent, 
>request,
dep->number);
if (ret) {
dwc3_trace(trace_dwc3_ep0, "failed to map request\n");
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 88fd30bf0c46..6929775bde57 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -191,7 +191,7 @@ void dwc3_gadget_giveback(struct dwc3_ep *dep, struct 
dwc3_request *req,
if (dwc->ep0_bounced && dep->number == 0)
dwc->ep0_bounced = false;
else
-   usb_gadget_unmap_request(>gadget, >request,
+   usb_gadget_unmap_request_by_dev(dwc->dev->parent, >request,
req->direction);
 
trace_dwc3_gadget_giveback(req);
@@ -335,7 +335,7 @@ static int dwc3_alloc_trb_pool(struct dwc3_ep *dep)
if (dep->trb_pool)
return 0;
 
-   dep->trb_pool = 

Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

[Felipe Balbi]

Hi,

Grygorii Strashko  writes:
> On 04/26/2016 09:17 AM, Felipe Balbi wrote:
>> 
>> Hi,
>> 
>> Grygorii Strashko  writes:
>>> Now not all DMA paremters configured properly for "xhci-hcd" platform
>>> device which is created manually. For example: dma_pfn_offset, dam_ops
>>> and iommu configuration will not corresponds "dwc3" devices
>>> configuration. As result, this will cause problems like wrong DMA
>>> addresses translation on platforms with LPAE enabled like Keystone 2.
>>>
>>> When platform is using DT boot mode the DMA configuration will be
>>> parsed and applied from DT, so, to fix this issue, reuse
>>> of_dma_configure() API and retrieve DMA configuartion for "xhci-hcd"
>>> from DWC3 device node.
>> 
>> patch is incomplete. You left out non-DT users which might suffer from
>> the same problem.
>> 
>
> Honestly, I don't know how to fix it gracefully for non-DT case.
> I can update commit message to mention that this is fix for DT case only.

no, that won't do :-) There are other users for this driver and they are
all "out-of-compliance" when it comes to DMA usage. Apparently, the
desired behavior is to pass correct device to DMA API which the gadget
side is already doing (see below). For the host side, the fix has to be
more involved.

Frankly, I'd prefer that DMA setup could be inherited from parent
device, then it wouldn't really matter and a bunch of this could be
simplified. Some sort of dma_inherit(struct device *dev, struct device
*parent) would go a long way, IMHO.

8< cut here 
commit 2725d6f974c4c268ae5fb746f8e3b33b76135aa8
Author: Felipe Balbi 
Date:   Tue Apr 19 16:18:12 2016 +0300

usb: dwc3: use parent device for DMA

our parent device is the one which was initialized
by either PCI or DeviceTree and that's the one which
is configured properly for DMA access.

Instead of copying DMA bits from parent to child,
let's just rely on parent device for the entire DMA
API.

Signed-off-by: Felipe Balbi 

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index c050a88c16d4..09e4ff71a50f 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -180,7 +180,7 @@ static void dwc3_frame_length_adjustment(struct dwc3 *dwc, 
u32 fladj)
 static void dwc3_free_one_event_buffer(struct dwc3 *dwc,
struct dwc3_event_buffer *evt)
 {
-   dma_free_coherent(dwc->dev, evt->length, evt->buf, evt->dma);
+   dma_free_coherent(dwc->dev->parent, evt->length, evt->buf, evt->dma);
 }
 
 /**
@@ -202,7 +202,7 @@ static struct dwc3_event_buffer 
*dwc3_alloc_one_event_buffer(struct dwc3 *dwc,
 
evt->dwc= dwc;
evt->length = length;
-   evt->buf= dma_alloc_coherent(dwc->dev, length,
+   evt->buf= dma_alloc_coherent(dwc->dev->parent, length,
>dma, GFP_KERNEL);
if (!evt->buf)
return ERR_PTR(-ENOMEM);
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 143deb420481..c78238dc76fc 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -967,7 +967,7 @@ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc,
u32 transfer_size = 0;
u32 maxpacket;
 
-   ret = usb_gadget_map_request(>gadget, >request,
+   ret = usb_gadget_map_request_by_dev(dwc->dev->parent, 
>request,
dep->number);
if (ret) {
dwc3_trace(trace_dwc3_ep0, "failed to map request\n");
@@ -995,7 +995,7 @@ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc,
dwc->ep0_bounce_addr, transfer_size,
DWC3_TRBCTL_CONTROL_DATA, false);
} else {
-   ret = usb_gadget_map_request(>gadget, >request,
+   ret = usb_gadget_map_request_by_dev(dwc->dev->parent, 
>request,
dep->number);
if (ret) {
dwc3_trace(trace_dwc3_ep0, "failed to map request\n");
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 88fd30bf0c46..6929775bde57 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -191,7 +191,7 @@ void dwc3_gadget_giveback(struct dwc3_ep *dep, struct 
dwc3_request *req,
if (dwc->ep0_bounced && dep->number == 0)
dwc->ep0_bounced = false;
else
-   usb_gadget_unmap_request(>gadget, >request,
+   usb_gadget_unmap_request_by_dev(dwc->dev->parent, >request,
req->direction);
 
trace_dwc3_gadget_giveback(req);
@@ -335,7 +335,7 @@ static int dwc3_alloc_trb_pool(struct dwc3_ep *dep)
if (dep->trb_pool)
return 0;
 
-   dep->trb_pool = dma_alloc_coherent(dwc->dev,
+   dep->trb_pool = dma_alloc_coherent(dwc->dev->parent,
sizeof(struct 

Re: [PATCH 02/19] radix-tree: Miscellaneous fixes

[NeilBrown]

On Fri, Apr 15 2016, Matthew Wilcox wrote:

> Typos, whitespace, grammar, line length, using the correct types, etc.
>
> Signed-off-by: Matthew Wilcox 
> Reviewed-by: Ross Zwisler 

>  
> -static inline void root_tag_clear(struct radix_tree_root *root, unsigned int 
> tag)
> +static inline void root_tag_clear(struct radix_tree_root *root, unsigned tag)

Changing "unsigned int" to "unsigned" - Bold.

>  {
>   root->gfp_mask &= (__force gfp_t)~(1 << (tag + __GFP_BITS_SHIFT));
>  }
> @@ -159,7 +159,7 @@ static inline void root_tag_clear_all(struct 
> radix_tree_root *root)
>  
>  static inline int root_tag_get(struct radix_tree_root *root, unsigned int 
> tag)

Not doing it uniformly - Priceless.

NeilBrown


signature.asc
Description: PGP signature

Re: [PATCH 02/19] radix-tree: Miscellaneous fixes

[NeilBrown]

On Fri, Apr 15 2016, Matthew Wilcox wrote:

> Typos, whitespace, grammar, line length, using the correct types, etc.
>
> Signed-off-by: Matthew Wilcox 
> Reviewed-by: Ross Zwisler 

>  
> -static inline void root_tag_clear(struct radix_tree_root *root, unsigned int 
> tag)
> +static inline void root_tag_clear(struct radix_tree_root *root, unsigned tag)

Changing "unsigned int" to "unsigned" - Bold.

>  {
>   root->gfp_mask &= (__force gfp_t)~(1 << (tag + __GFP_BITS_SHIFT));
>  }
> @@ -159,7 +159,7 @@ static inline void root_tag_clear_all(struct 
> radix_tree_root *root)
>  
>  static inline int root_tag_get(struct radix_tree_root *root, unsigned int 
> tag)

Not doing it uniformly - Priceless.

NeilBrown


signature.asc
Description: PGP signature

Re: [PATCH 05/12] nvmem: vif610-ocotp: remove nvmem regmap dependency

[maitysanchayan]

Hello Srinivas,

On 16-04-24 20:28:09, Srinivas Kandagatla wrote:
> This patch moves to nvmem support in the driver to use callback
> instead of regmap.

Minor nit, it says "vif610-octop" it should have been vf610-ocotp.

For what it's worth, I tested this on Colibri Vybrid VF61 for a while and
all seems to work fine.

So with the testing for vf610-ocotp driver other than the minor nit

Acked-by: Sanchayan Maity 

Regards,
Sanchayan.

> 
> Signed-off-by: Srinivas Kandagatla 
> ---
>  drivers/nvmem/vf610-ocotp.c | 44 ++--
>  1 file changed, 10 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/nvmem/vf610-ocotp.c b/drivers/nvmem/vf610-ocotp.c
> index 8641319..72e4faa 100644
> --- a/drivers/nvmem/vf610-ocotp.c
> +++ b/drivers/nvmem/vf610-ocotp.c
> @@ -25,7 +25,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  
>  /* OCOTP Register Offsets */
> @@ -152,23 +151,16 @@ static int vf610_get_fuse_address(int base_addr_offset)
>   return -EINVAL;
>  }
>  
> -static int vf610_ocotp_write(void *context, const void *data, size_t count)
> -{
> - return 0;
> -}
> -
> -static int vf610_ocotp_read(void *context,
> - const void *off, size_t reg_size,
> - void *val, size_t val_size)
> +static int vf610_ocotp_read(void *context, unsigned int offset,
> + void *val, size_t bytes)
>  {
>   struct vf610_ocotp *ocotp = context;
>   void __iomem *base = ocotp->base;
> - unsigned int offset = *(u32 *)off;
>   u32 reg, *buf = val;
>   int fuse_addr;
>   int ret;
>  
> - while (val_size > 0) {
> + while (bytes > 0) {
>   fuse_addr = vf610_get_fuse_address(offset);
>   if (fuse_addr > 0) {
>   writel(ocotp->timing, base + OCOTP_TIMING);
> @@ -205,29 +197,19 @@ static int vf610_ocotp_read(void *context,
>   }
>  
>   buf++;
> - val_size--;
> - offset += reg_size;
> + bytes -= 4;
> + offset += 4;
>   }
>  
>   return 0;
>  }
>  
> -static struct regmap_bus vf610_ocotp_bus = {
> - .read = vf610_ocotp_read,
> - .write = vf610_ocotp_write,
> - .reg_format_endian_default = REGMAP_ENDIAN_NATIVE,
> - .val_format_endian_default = REGMAP_ENDIAN_NATIVE,
> -};
> -
> -static struct regmap_config ocotp_regmap_config = {
> - .reg_bits = 32,
> - .val_bits = 32,
> - .reg_stride = 4,
> -};
> -
>  static struct nvmem_config ocotp_config = {
>   .name = "ocotp",
>   .owner = THIS_MODULE,
> + .stride = 4,
> + .word_size = 4,
> + .reg_read = vf610_ocotp_read,
>  };
>  
>  static const struct of_device_id ocotp_of_match[] = {
> @@ -247,7 +229,6 @@ static int vf610_ocotp_probe(struct platform_device *pdev)
>  {
>   struct device *dev = >dev;
>   struct resource *res;
> - struct regmap *regmap;
>   struct vf610_ocotp *ocotp_dev;
>  
>   ocotp_dev = devm_kzalloc(>dev,
> @@ -267,13 +248,8 @@ static int vf610_ocotp_probe(struct platform_device 
> *pdev)
>   return PTR_ERR(ocotp_dev->clk);
>   }
>  
> - ocotp_regmap_config.max_register = resource_size(res);
> - regmap = devm_regmap_init(dev,
> - _ocotp_bus, ocotp_dev, _regmap_config);
> - if (IS_ERR(regmap)) {
> - dev_err(dev, "regmap init failed\n");
> - return PTR_ERR(regmap);
> - }
> + ocotp_config.size = resource_size(res);
> + ocotp_config.priv = ocotp_dev;
>   ocotp_config.dev = dev;
>  
>   ocotp_dev->nvmem = nvmem_register(_config);
> -- 
> 2.5.0
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Double-Fetch bug in Linux-4.5/drivers/scsi/aacraid/commctrl.c

[Julia Lawall]

On Tue, 26 Apr 2016, Kees Cook wrote:

> On Mon, Apr 25, 2016 at 7:50 AM, Pengfei Wang  wrote:
> > Hello,
> >
> > I found this Double-Fetch bug in Linux-4.5/drivers/scsi/aacraid/commctrl.c
> > when I was examining the source code.
> 
> Thanks for these reports! I wrote a coccinelle script to find these,
> but it requires some manual checking. For what it's worth, it found
> your report as well:
> 
> ./drivers/scsi/aacraid/commctrl.c:116:5-19: potentially dangerous
> second copy_from_user()
> 
> So I should probably get this added to the coccicheck run... Maybe it
> can get some clean up from Julia. :)

I looked a bit at the results, and didn't see anything obvious.  What is 
the problem, exactly, and what would be a characteristic of a false 
positive?

thanks,
julia

> virtual report
> virtual org
> 
> @cfu_twice@
> position p;
> identifier src;
> expression dest1, dest2, size1, size2, offset;
> @@
> 
> *copy_from_user(dest1, src, size1)
>  ... when != src = offset
>  when != src += offset
> *copy_from_user@p(dest2, src, size2)
> 
> @script:python depends on org@
> p << cfu_twice.p;
> @@
> 
> cocci.print_main("potentially dangerous second copy_from_user()",p)
> 
> @script:python depends on report@
> p << cfu_twice.p;
> @@
> 
> coccilib.report.print_report(p[0],"potentially dangerous second
> copy_from_user()")
> 
> 
> It would be great to have some one go through all the reports to see
> which are legit. I'll send separate emails with the patch for
> coccicheck and the output.
> 
> -Kees
> 
> >
> > In function ioctl_send_fib(), the driver fetches user space data by pointer
> > arg via copy_from_user(), and this happens twice at line 81 and line 116
> > respectively. The first fetched value (stored in kfib) is used to get the
> > header and calculate the size at line 90 so as to copy the whole message
> > later at line 116, which means the copy size of the whole message is based
> > on the old value that came from the first fetch. Besides, the whole message
> > copied in the  second fetch also contains the header.
> >
> > However, when the function processes the message after the second fetch at
> > line 130, it uses kfib->header.Size that came from the second fetch, which
> > might be different from the one came from the first fetch as well as
> > calculated the size to copy the message from user space to driver.
> >
> > If the kfib->header.Size is modified by a user thread under race condition
> > between the fetch operations, for example changing to a very large value,
> > this will lead to over-boundary access or other serious consequences in
> > function aac_fib_send().
> >
> > I also reported this to bugzilla,
> > https://bugzilla.kernel.org/show_bug.cgi?id=116751
> >
> > I am expecting a reply to confirm this, thank you!
> >
> >
> >
> >
> >
> > Kind regards
> > Pengfei
> >
> 
> 
> 
> -- 
> Kees Cook
> Chrome OS & Brillo Security
> 

Re: [PATCH 05/12] nvmem: vif610-ocotp: remove nvmem regmap dependency

[maitysanchayan]

Hello Srinivas,

On 16-04-24 20:28:09, Srinivas Kandagatla wrote:
> This patch moves to nvmem support in the driver to use callback
> instead of regmap.

Minor nit, it says "vif610-octop" it should have been vf610-ocotp.

For what it's worth, I tested this on Colibri Vybrid VF61 for a while and
all seems to work fine.

So with the testing for vf610-ocotp driver other than the minor nit

Acked-by: Sanchayan Maity 

Regards,
Sanchayan.

> 
> Signed-off-by: Srinivas Kandagatla 
> ---
>  drivers/nvmem/vf610-ocotp.c | 44 ++--
>  1 file changed, 10 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/nvmem/vf610-ocotp.c b/drivers/nvmem/vf610-ocotp.c
> index 8641319..72e4faa 100644
> --- a/drivers/nvmem/vf610-ocotp.c
> +++ b/drivers/nvmem/vf610-ocotp.c
> @@ -25,7 +25,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  
>  /* OCOTP Register Offsets */
> @@ -152,23 +151,16 @@ static int vf610_get_fuse_address(int base_addr_offset)
>   return -EINVAL;
>  }
>  
> -static int vf610_ocotp_write(void *context, const void *data, size_t count)
> -{
> - return 0;
> -}
> -
> -static int vf610_ocotp_read(void *context,
> - const void *off, size_t reg_size,
> - void *val, size_t val_size)
> +static int vf610_ocotp_read(void *context, unsigned int offset,
> + void *val, size_t bytes)
>  {
>   struct vf610_ocotp *ocotp = context;
>   void __iomem *base = ocotp->base;
> - unsigned int offset = *(u32 *)off;
>   u32 reg, *buf = val;
>   int fuse_addr;
>   int ret;
>  
> - while (val_size > 0) {
> + while (bytes > 0) {
>   fuse_addr = vf610_get_fuse_address(offset);
>   if (fuse_addr > 0) {
>   writel(ocotp->timing, base + OCOTP_TIMING);
> @@ -205,29 +197,19 @@ static int vf610_ocotp_read(void *context,
>   }
>  
>   buf++;
> - val_size--;
> - offset += reg_size;
> + bytes -= 4;
> + offset += 4;
>   }
>  
>   return 0;
>  }
>  
> -static struct regmap_bus vf610_ocotp_bus = {
> - .read = vf610_ocotp_read,
> - .write = vf610_ocotp_write,
> - .reg_format_endian_default = REGMAP_ENDIAN_NATIVE,
> - .val_format_endian_default = REGMAP_ENDIAN_NATIVE,
> -};
> -
> -static struct regmap_config ocotp_regmap_config = {
> - .reg_bits = 32,
> - .val_bits = 32,
> - .reg_stride = 4,
> -};
> -
>  static struct nvmem_config ocotp_config = {
>   .name = "ocotp",
>   .owner = THIS_MODULE,
> + .stride = 4,
> + .word_size = 4,
> + .reg_read = vf610_ocotp_read,
>  };
>  
>  static const struct of_device_id ocotp_of_match[] = {
> @@ -247,7 +229,6 @@ static int vf610_ocotp_probe(struct platform_device *pdev)
>  {
>   struct device *dev = >dev;
>   struct resource *res;
> - struct regmap *regmap;
>   struct vf610_ocotp *ocotp_dev;
>  
>   ocotp_dev = devm_kzalloc(>dev,
> @@ -267,13 +248,8 @@ static int vf610_ocotp_probe(struct platform_device 
> *pdev)
>   return PTR_ERR(ocotp_dev->clk);
>   }
>  
> - ocotp_regmap_config.max_register = resource_size(res);
> - regmap = devm_regmap_init(dev,
> - _ocotp_bus, ocotp_dev, _regmap_config);
> - if (IS_ERR(regmap)) {
> - dev_err(dev, "regmap init failed\n");
> - return PTR_ERR(regmap);
> - }
> + ocotp_config.size = resource_size(res);
> + ocotp_config.priv = ocotp_dev;
>   ocotp_config.dev = dev;
>  
>   ocotp_dev->nvmem = nvmem_register(_config);
> -- 
> 2.5.0
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Double-Fetch bug in Linux-4.5/drivers/scsi/aacraid/commctrl.c

[Julia Lawall]

On Tue, 26 Apr 2016, Kees Cook wrote:

> On Mon, Apr 25, 2016 at 7:50 AM, Pengfei Wang  wrote:
> > Hello,
> >
> > I found this Double-Fetch bug in Linux-4.5/drivers/scsi/aacraid/commctrl.c
> > when I was examining the source code.
> 
> Thanks for these reports! I wrote a coccinelle script to find these,
> but it requires some manual checking. For what it's worth, it found
> your report as well:
> 
> ./drivers/scsi/aacraid/commctrl.c:116:5-19: potentially dangerous
> second copy_from_user()
> 
> So I should probably get this added to the coccicheck run... Maybe it
> can get some clean up from Julia. :)

I looked a bit at the results, and didn't see anything obvious.  What is 
the problem, exactly, and what would be a characteristic of a false 
positive?

thanks,
julia

> virtual report
> virtual org
> 
> @cfu_twice@
> position p;
> identifier src;
> expression dest1, dest2, size1, size2, offset;
> @@
> 
> *copy_from_user(dest1, src, size1)
>  ... when != src = offset
>  when != src += offset
> *copy_from_user@p(dest2, src, size2)
> 
> @script:python depends on org@
> p << cfu_twice.p;
> @@
> 
> cocci.print_main("potentially dangerous second copy_from_user()",p)
> 
> @script:python depends on report@
> p << cfu_twice.p;
> @@
> 
> coccilib.report.print_report(p[0],"potentially dangerous second
> copy_from_user()")
> 
> 
> It would be great to have some one go through all the reports to see
> which are legit. I'll send separate emails with the patch for
> coccicheck and the output.
> 
> -Kees
> 
> >
> > In function ioctl_send_fib(), the driver fetches user space data by pointer
> > arg via copy_from_user(), and this happens twice at line 81 and line 116
> > respectively. The first fetched value (stored in kfib) is used to get the
> > header and calculate the size at line 90 so as to copy the whole message
> > later at line 116, which means the copy size of the whole message is based
> > on the old value that came from the first fetch. Besides, the whole message
> > copied in the  second fetch also contains the header.
> >
> > However, when the function processes the message after the second fetch at
> > line 130, it uses kfib->header.Size that came from the second fetch, which
> > might be different from the one came from the first fetch as well as
> > calculated the size to copy the message from user space to driver.
> >
> > If the kfib->header.Size is modified by a user thread under race condition
> > between the fetch operations, for example changing to a very large value,
> > this will lead to over-boundary access or other serious consequences in
> > function aac_fib_send().
> >
> > I also reported this to bugzilla,
> > https://bugzilla.kernel.org/show_bug.cgi?id=116751
> >
> > I am expecting a reply to confirm this, thank you!
> >
> >
> >
> >
> >
> > Kind regards
> > Pengfei
> >
> 
> 
> 
> -- 
> Kees Cook
> Chrome OS & Brillo Security
> 

Re: [RESEND PATCH v2 7/7] usb: xhci: plat: add vbus regulator control

[Felipe Balbi]

Hi,

Jisheng Zhang  writes:
> The Marvell BG4CT STB board has board level vbus control through gpio.
> This patch adds the vbus regulator control to support this board.
>
> Signed-off-by: Jisheng Zhang 
> ---
>  drivers/usb/host/xhci-plat.c | 40 +++-
>  drivers/usb/host/xhci.h  |  2 ++
>  2 files changed, 41 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index d7f4f3c..0310c13 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -178,6 +179,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
>   struct clk  *clk;
>   struct usb_phy  *usb_phy;
>   struct phy  *phy;
> + struct regulator*vbus;
>   int ret;
>   int irq;
>  
> @@ -249,13 +251,30 @@ static int xhci_plat_probe(struct platform_device *pdev)
>  
>   device_wakeup_enable(hcd->self.controller);
>  
> + vbus = devm_regulator_get(>dev, "vbus");

devm_regulator_get_optional() ??

> + if (PTR_ERR(vbus) == -ENODEV) {
> + vbus = NULL;
> + } else if (IS_ERR(vbus)) {
> + ret = PTR_ERR(vbus);
> + goto disable_clk;
> + } else if (vbus) {
> + ret = regulator_enable(vbus);
> + if (ret) {
> + dev_err(>dev,
> + "failed to enable usb vbus regulator: %d\n",
> + ret);
> + goto disable_clk;
> + }
> + }
> +
>   xhci->clk = clk;
> + xhci->vbus = vbus;
>   xhci->main_hcd = hcd;
>   xhci->shared_hcd = usb_create_shared_hcd(driver, >dev,
>   dev_name(>dev), hcd);
>   if (!xhci->shared_hcd) {
>   ret = -ENOMEM;
> - goto disable_clk;
> + goto disable_vbus;
>   }
>  
>   if ((node && of_property_read_bool(node, "usb3-lpm-capable")) ||
> @@ -323,6 +342,10 @@ disable_usb2_phy:
>  put_usb3_hcd:
>   usb_put_hcd(xhci->shared_hcd);
>  
> +disable_vbus:
> + if (vbus)
> + regulator_disable(vbus);
> +
>  disable_clk:
>   clk_disable_unprepare(clk);
>  
> @@ -337,6 +360,7 @@ static int xhci_plat_remove(struct platform_device *dev)
>   struct usb_hcd  *hcd = platform_get_drvdata(dev);
>   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
>   struct clk *clk = xhci->clk;
> + struct regulator *vbus = xhci->vbus;
>  
>   usb_remove_hcd(xhci->shared_hcd);
>   xhci_plat_phy_exit(xhci->shared_hcd);
> @@ -347,6 +371,9 @@ static int xhci_plat_remove(struct platform_device *dev)
>   clk_disable_unprepare(clk);
>   usb_put_hcd(hcd);
>  
> + if (vbus)
> + regulator_disable(vbus);
> +
>   return 0;
>  }
>  
> @@ -356,6 +383,7 @@ static int xhci_plat_suspend(struct device *dev)
>   int ret;
>   struct usb_hcd  *hcd = dev_get_drvdata(dev);
>   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> + struct regulator *vbus = xhci->vbus;
>  
>   /*
>* xhci_suspend() needs `do_wakeup` to know whether host is allowed
> @@ -373,6 +401,9 @@ static int xhci_plat_suspend(struct device *dev)
>   xhci_plat_phy_exit(hcd);
>   clk_disable_unprepare(xhci->clk);
>  
> + if (vbus)
> + ret = regulator_disable(vbus);
> +
>   return ret;
>  }
>  
> @@ -381,11 +412,18 @@ static int xhci_plat_resume(struct device *dev)
>   int ret;
>   struct usb_hcd  *hcd = dev_get_drvdata(dev);
>   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> + struct regulator *vbus = xhci->vbus;
>  
>   ret = clk_prepare_enable(xhci->clk);
>   if (ret)
>   return ret;
>  
> + if (vbus) {
> + ret = regulator_enable(vbus);
> + if (ret)
> + return ret;
> + }
> +
>   ret = xhci_plat_phy_init(hcd);
>   if (ret)
>   return ret;
> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
> index 6c629c9..5fa8662 100644
> --- a/drivers/usb/host/xhci.h
> +++ b/drivers/usb/host/xhci.h
> @@ -1550,6 +1550,8 @@ struct xhci_hcd {
>   struct msix_entry   *msix_entries;
>   /* optional clock */
>   struct clk  *clk;
> + /* optional regulator */
> + struct regulator*vbus;
>   /* data structures */
>   struct xhci_device_context_array *dcbaa;
>   struct xhci_ring*cmd_ring;
> -- 
> 2.8.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
balbi


signature.asc
Description: PGP signature

Re: + mm-zswap-use-workqueue-to-destroy-pool.patch added to -mm tree

[Sergey Senozhatsky]

Hello,

On (04/26/16 16:52), a...@linux-foundation.org wrote:
[..]
> -static void __zswap_pool_release(struct rcu_head *head)
> +static void __zswap_pool_release(struct work_struct *work)
>  {
> - struct zswap_pool *pool = container_of(head, typeof(*pool), rcu_head);
> + struct zswap_pool *pool = container_of(work, typeof(*pool), work);
> +
> + synchronize_rcu();
>  
>   /* nobody should have been able to get a kref... */
>   WARN_ON(kref_get_unless_zero(>kref));
> @@ -674,7 +676,9 @@ static void __zswap_pool_empty(struct kr
>   WARN_ON(pool == zswap_pool_current());
>  
>   list_del_rcu(>list);
> - call_rcu(>rcu_head, __zswap_pool_release);
> +
> + INIT_WORK(>work, __zswap_pool_release);
> + schedule_work(>work);
>  
>   spin_unlock(_pools_lock);
>  }
> _
> 
> Patches currently in -mm which might be from ddstr...@ieee.org are
> 
> mm-zpool-use-workqueue-for-zpool_destroy.patch
> mm-zswap-use-workqueue-to-destroy-pool.patch

I think only mm-zswap-use-workqueue-to-destroy-pool.patch is
needed.

-ss

Re: + mm-zswap-use-workqueue-to-destroy-pool.patch added to -mm tree

[Sergey Senozhatsky]

Hello,

On (04/26/16 16:52), a...@linux-foundation.org wrote:
[..]
> -static void __zswap_pool_release(struct rcu_head *head)
> +static void __zswap_pool_release(struct work_struct *work)
>  {
> - struct zswap_pool *pool = container_of(head, typeof(*pool), rcu_head);
> + struct zswap_pool *pool = container_of(work, typeof(*pool), work);
> +
> + synchronize_rcu();
>  
>   /* nobody should have been able to get a kref... */
>   WARN_ON(kref_get_unless_zero(>kref));
> @@ -674,7 +676,9 @@ static void __zswap_pool_empty(struct kr
>   WARN_ON(pool == zswap_pool_current());
>  
>   list_del_rcu(>list);
> - call_rcu(>rcu_head, __zswap_pool_release);
> +
> + INIT_WORK(>work, __zswap_pool_release);
> + schedule_work(>work);
>  
>   spin_unlock(_pools_lock);
>  }
> _
> 
> Patches currently in -mm which might be from ddstr...@ieee.org are
> 
> mm-zpool-use-workqueue-for-zpool_destroy.patch
> mm-zswap-use-workqueue-to-destroy-pool.patch

I think only mm-zswap-use-workqueue-to-destroy-pool.patch is
needed.

-ss

Re: [RESEND PATCH v2 7/7] usb: xhci: plat: add vbus regulator control

[Felipe Balbi]

Hi,

Jisheng Zhang  writes:
> The Marvell BG4CT STB board has board level vbus control through gpio.
> This patch adds the vbus regulator control to support this board.
>
> Signed-off-by: Jisheng Zhang 
> ---
>  drivers/usb/host/xhci-plat.c | 40 +++-
>  drivers/usb/host/xhci.h  |  2 ++
>  2 files changed, 41 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index d7f4f3c..0310c13 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -178,6 +179,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
>   struct clk  *clk;
>   struct usb_phy  *usb_phy;
>   struct phy  *phy;
> + struct regulator*vbus;
>   int ret;
>   int irq;
>  
> @@ -249,13 +251,30 @@ static int xhci_plat_probe(struct platform_device *pdev)
>  
>   device_wakeup_enable(hcd->self.controller);
>  
> + vbus = devm_regulator_get(>dev, "vbus");

devm_regulator_get_optional() ??

> + if (PTR_ERR(vbus) == -ENODEV) {
> + vbus = NULL;
> + } else if (IS_ERR(vbus)) {
> + ret = PTR_ERR(vbus);
> + goto disable_clk;
> + } else if (vbus) {
> + ret = regulator_enable(vbus);
> + if (ret) {
> + dev_err(>dev,
> + "failed to enable usb vbus regulator: %d\n",
> + ret);
> + goto disable_clk;
> + }
> + }
> +
>   xhci->clk = clk;
> + xhci->vbus = vbus;
>   xhci->main_hcd = hcd;
>   xhci->shared_hcd = usb_create_shared_hcd(driver, >dev,
>   dev_name(>dev), hcd);
>   if (!xhci->shared_hcd) {
>   ret = -ENOMEM;
> - goto disable_clk;
> + goto disable_vbus;
>   }
>  
>   if ((node && of_property_read_bool(node, "usb3-lpm-capable")) ||
> @@ -323,6 +342,10 @@ disable_usb2_phy:
>  put_usb3_hcd:
>   usb_put_hcd(xhci->shared_hcd);
>  
> +disable_vbus:
> + if (vbus)
> + regulator_disable(vbus);
> +
>  disable_clk:
>   clk_disable_unprepare(clk);
>  
> @@ -337,6 +360,7 @@ static int xhci_plat_remove(struct platform_device *dev)
>   struct usb_hcd  *hcd = platform_get_drvdata(dev);
>   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
>   struct clk *clk = xhci->clk;
> + struct regulator *vbus = xhci->vbus;
>  
>   usb_remove_hcd(xhci->shared_hcd);
>   xhci_plat_phy_exit(xhci->shared_hcd);
> @@ -347,6 +371,9 @@ static int xhci_plat_remove(struct platform_device *dev)
>   clk_disable_unprepare(clk);
>   usb_put_hcd(hcd);
>  
> + if (vbus)
> + regulator_disable(vbus);
> +
>   return 0;
>  }
>  
> @@ -356,6 +383,7 @@ static int xhci_plat_suspend(struct device *dev)
>   int ret;
>   struct usb_hcd  *hcd = dev_get_drvdata(dev);
>   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> + struct regulator *vbus = xhci->vbus;
>  
>   /*
>* xhci_suspend() needs `do_wakeup` to know whether host is allowed
> @@ -373,6 +401,9 @@ static int xhci_plat_suspend(struct device *dev)
>   xhci_plat_phy_exit(hcd);
>   clk_disable_unprepare(xhci->clk);
>  
> + if (vbus)
> + ret = regulator_disable(vbus);
> +
>   return ret;
>  }
>  
> @@ -381,11 +412,18 @@ static int xhci_plat_resume(struct device *dev)
>   int ret;
>   struct usb_hcd  *hcd = dev_get_drvdata(dev);
>   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> + struct regulator *vbus = xhci->vbus;
>  
>   ret = clk_prepare_enable(xhci->clk);
>   if (ret)
>   return ret;
>  
> + if (vbus) {
> + ret = regulator_enable(vbus);
> + if (ret)
> + return ret;
> + }
> +
>   ret = xhci_plat_phy_init(hcd);
>   if (ret)
>   return ret;
> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
> index 6c629c9..5fa8662 100644
> --- a/drivers/usb/host/xhci.h
> +++ b/drivers/usb/host/xhci.h
> @@ -1550,6 +1550,8 @@ struct xhci_hcd {
>   struct msix_entry   *msix_entries;
>   /* optional clock */
>   struct clk  *clk;
> + /* optional regulator */
> + struct regulator*vbus;
>   /* data structures */
>   struct xhci_device_context_array *dcbaa;
>   struct xhci_ring*cmd_ring;
> -- 
> 2.8.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
balbi


signature.asc
Description: PGP signature

Re: [RESEND PATCH v2 6/7] usb: xhci: plat: add generic PHY support

[Felipe Balbi]

Hi,

Jisheng Zhang  writes:
> Marvell BG4CT SoC needs two phy: one for usb2 and another for usb3. Add
> the calls to retrieve generic PHY to xhci plat in order to support this.
>
> Signed-off-by: Jisheng Zhang 
> ---
>  drivers/usb/host/xhci-plat.c | 87 
> ++--
>  1 file changed, 75 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 83669d0..d7f4f3c 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -134,6 +135,37 @@ static const struct of_device_id usb_xhci_of_match[] = {
>  MODULE_DEVICE_TABLE(of, usb_xhci_of_match);
>  #endif
>  
> +static int xhci_plat_phy_init(struct usb_hcd *hcd)
> +{
> + int ret;
> +
> + if (hcd->phy) {
> + ret = phy_init(hcd->phy);
> + if (ret)
> + return ret;
> +
> + ret = phy_power_on(hcd->phy);
> + if (ret) {
> + phy_exit(hcd->phy);
> + return ret;
> + }
> + } else {
> + ret = usb_phy_init(hcd->usb_phy);
> + }
> +
> + return ret;
> +}
> +
> +static void xhci_plat_phy_exit(struct usb_hcd *hcd)
> +{
> + if (hcd->phy) {
> + phy_power_off(hcd->phy);
> + phy_exit(hcd->phy);
> + } else {
> + usb_phy_shutdown(hcd->usb_phy);
> + }
> +}
> +
>  static int xhci_plat_probe(struct platform_device *pdev)
>  {
>   struct device_node  *node = pdev->dev.of_node;
> @@ -145,6 +177,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
>   struct usb_hcd  *hcd;
>   struct clk  *clk;
>   struct usb_phy  *usb_phy;
> + struct phy  *phy;

so, one phy driver using USB PHY layer and another using generic PHY
layer ? Why ? I think the first thing your series should do would be to
add proper suport for both APIs with two PHYs and make them all optional
for xhci-plat.

> @@ -232,22 +265,44 @@ static int xhci_plat_probe(struct platform_device *pdev)
>   if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
>   xhci->shared_hcd->can_do_streams = 1;
>  
> + hcd->phy = devm_phy_get(>dev, "usb2-phy");
> + if (IS_ERR(hcd->phy)) {
> + ret = PTR_ERR(hcd->phy);
> + if (ret == -EPROBE_DEFER)
> + goto put_usb3_hcd;
> + hcd->phy = NULL;
> + }
> +
> + phy = devm_phy_get(>dev, "usb-phy");
> + if (IS_ERR(phy)) {
> + ret = PTR_ERR(phy);
> + if (ret == -EPROBE_DEFER)
> + goto put_usb3_hcd;
> + phy = NULL;
> + }
> +
>   usb_phy = devm_usb_get_phy_by_phandle(>dev, "usb-phy", 0);
>   if (IS_ERR(usb_phy)) {
>   ret = PTR_ERR(usb_phy);
>   if (ret == -EPROBE_DEFER)
>   goto put_usb3_hcd;
>   usb_phy = NULL;
> - } else {
> - ret = usb_phy_init(usb_phy);
> - if (ret)
> - goto put_usb3_hcd;
>   }
> +
>   xhci->shared_hcd->usb_phy = usb_phy;
> + xhci->shared_hcd->phy = phy;
> +
> + ret = xhci_plat_phy_init(hcd);
> + if (ret)
> + goto put_usb3_hcd;
> +
> + ret = xhci_plat_phy_init(xhci->shared_hcd);
> + if (ret)
> + goto disable_usb2_phy;
>  
>   ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
>   if (ret)
> - goto disable_usb_phy;
> + goto disable_usb3_phy;
>  
>   ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
>   if (ret)
> @@ -259,8 +314,11 @@ static int xhci_plat_probe(struct platform_device *pdev)
>  dealloc_usb2_hcd:
>   usb_remove_hcd(hcd);
>  
> -disable_usb_phy:
> - usb_phy_shutdown(usb_phy);
> +disable_usb3_phy:
> + xhci_plat_phy_exit(xhci->shared_hcd);
> +
> +disable_usb2_phy:
> + xhci_plat_phy_exit(hcd);
>  
>  put_usb3_hcd:
>   usb_put_hcd(xhci->shared_hcd);
> @@ -281,11 +339,11 @@ static int xhci_plat_remove(struct platform_device *dev)
>   struct clk *clk = xhci->clk;
>  
>   usb_remove_hcd(xhci->shared_hcd);
> - usb_phy_shutdown(xhci->shared_hcd->usb_phy);
> -
> - usb_remove_hcd(hcd);
> + xhci_plat_phy_exit(xhci->shared_hcd);
>   usb_put_hcd(xhci->shared_hcd);
>  
> + usb_remove_hcd(hcd);
> + xhci_plat_phy_exit(hcd);
>   clk_disable_unprepare(clk);
>   usb_put_hcd(hcd);
>  
> @@ -311,7 +369,8 @@ static int xhci_plat_suspend(struct device *dev)
>   if (ret)
>   return ret;
>  
> - usb_phy_shutdown(xhci->shared_hcd->usb_phy);
> + xhci_plat_phy_exit(xhci->shared_hcd);
> + xhci_plat_phy_exit(hcd);
>   clk_disable_unprepare(xhci->clk);
>  
>   return ret;
> @@ -327,7 +386,11 @@ static int xhci_plat_resume(struct device *dev)
>   if 

Re: [RESEND PATCH v2 6/7] usb: xhci: plat: add generic PHY support

[Felipe Balbi]

Hi,

Jisheng Zhang  writes:
> Marvell BG4CT SoC needs two phy: one for usb2 and another for usb3. Add
> the calls to retrieve generic PHY to xhci plat in order to support this.
>
> Signed-off-by: Jisheng Zhang 
> ---
>  drivers/usb/host/xhci-plat.c | 87 
> ++--
>  1 file changed, 75 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 83669d0..d7f4f3c 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -134,6 +135,37 @@ static const struct of_device_id usb_xhci_of_match[] = {
>  MODULE_DEVICE_TABLE(of, usb_xhci_of_match);
>  #endif
>  
> +static int xhci_plat_phy_init(struct usb_hcd *hcd)
> +{
> + int ret;
> +
> + if (hcd->phy) {
> + ret = phy_init(hcd->phy);
> + if (ret)
> + return ret;
> +
> + ret = phy_power_on(hcd->phy);
> + if (ret) {
> + phy_exit(hcd->phy);
> + return ret;
> + }
> + } else {
> + ret = usb_phy_init(hcd->usb_phy);
> + }
> +
> + return ret;
> +}
> +
> +static void xhci_plat_phy_exit(struct usb_hcd *hcd)
> +{
> + if (hcd->phy) {
> + phy_power_off(hcd->phy);
> + phy_exit(hcd->phy);
> + } else {
> + usb_phy_shutdown(hcd->usb_phy);
> + }
> +}
> +
>  static int xhci_plat_probe(struct platform_device *pdev)
>  {
>   struct device_node  *node = pdev->dev.of_node;
> @@ -145,6 +177,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
>   struct usb_hcd  *hcd;
>   struct clk  *clk;
>   struct usb_phy  *usb_phy;
> + struct phy  *phy;

so, one phy driver using USB PHY layer and another using generic PHY
layer ? Why ? I think the first thing your series should do would be to
add proper suport for both APIs with two PHYs and make them all optional
for xhci-plat.

> @@ -232,22 +265,44 @@ static int xhci_plat_probe(struct platform_device *pdev)
>   if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
>   xhci->shared_hcd->can_do_streams = 1;
>  
> + hcd->phy = devm_phy_get(>dev, "usb2-phy");
> + if (IS_ERR(hcd->phy)) {
> + ret = PTR_ERR(hcd->phy);
> + if (ret == -EPROBE_DEFER)
> + goto put_usb3_hcd;
> + hcd->phy = NULL;
> + }
> +
> + phy = devm_phy_get(>dev, "usb-phy");
> + if (IS_ERR(phy)) {
> + ret = PTR_ERR(phy);
> + if (ret == -EPROBE_DEFER)
> + goto put_usb3_hcd;
> + phy = NULL;
> + }
> +
>   usb_phy = devm_usb_get_phy_by_phandle(>dev, "usb-phy", 0);
>   if (IS_ERR(usb_phy)) {
>   ret = PTR_ERR(usb_phy);
>   if (ret == -EPROBE_DEFER)
>   goto put_usb3_hcd;
>   usb_phy = NULL;
> - } else {
> - ret = usb_phy_init(usb_phy);
> - if (ret)
> - goto put_usb3_hcd;
>   }
> +
>   xhci->shared_hcd->usb_phy = usb_phy;
> + xhci->shared_hcd->phy = phy;
> +
> + ret = xhci_plat_phy_init(hcd);
> + if (ret)
> + goto put_usb3_hcd;
> +
> + ret = xhci_plat_phy_init(xhci->shared_hcd);
> + if (ret)
> + goto disable_usb2_phy;
>  
>   ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
>   if (ret)
> - goto disable_usb_phy;
> + goto disable_usb3_phy;
>  
>   ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
>   if (ret)
> @@ -259,8 +314,11 @@ static int xhci_plat_probe(struct platform_device *pdev)
>  dealloc_usb2_hcd:
>   usb_remove_hcd(hcd);
>  
> -disable_usb_phy:
> - usb_phy_shutdown(usb_phy);
> +disable_usb3_phy:
> + xhci_plat_phy_exit(xhci->shared_hcd);
> +
> +disable_usb2_phy:
> + xhci_plat_phy_exit(hcd);
>  
>  put_usb3_hcd:
>   usb_put_hcd(xhci->shared_hcd);
> @@ -281,11 +339,11 @@ static int xhci_plat_remove(struct platform_device *dev)
>   struct clk *clk = xhci->clk;
>  
>   usb_remove_hcd(xhci->shared_hcd);
> - usb_phy_shutdown(xhci->shared_hcd->usb_phy);
> -
> - usb_remove_hcd(hcd);
> + xhci_plat_phy_exit(xhci->shared_hcd);
>   usb_put_hcd(xhci->shared_hcd);
>  
> + usb_remove_hcd(hcd);
> + xhci_plat_phy_exit(hcd);
>   clk_disable_unprepare(clk);
>   usb_put_hcd(hcd);
>  
> @@ -311,7 +369,8 @@ static int xhci_plat_suspend(struct device *dev)
>   if (ret)
>   return ret;
>  
> - usb_phy_shutdown(xhci->shared_hcd->usb_phy);
> + xhci_plat_phy_exit(xhci->shared_hcd);
> + xhci_plat_phy_exit(hcd);
>   clk_disable_unprepare(xhci->clk);
>  
>   return ret;
> @@ -327,7 +386,11 @@ static int xhci_plat_resume(struct device *dev)
>   if (ret)
>   return ret;
>  
> - 

Re: [PATCH V6 05/13] acpi, pci: Support IO resources when parsing PCI host bridge resources.

[Jon Masters]

On 04/26/2016 10:39 PM, Bjorn Helgaas wrote:
> On Fri, Apr 15, 2016 at 07:06:40PM +0200, Tomasz Nowicki wrote:
>> Platforms that have memory mapped IO port (such as ARM64) need special
>> handling for PCI I/O resources. For host bridge's resource probing case
>> these resources need to be fixed up with 
>> pci_register_io_range/pci_remap_iospace etc.
> 
> ia64 also has memory-mapped I/O port space.

The specific references of interest to anyone here are:

*). Volume 2, Part 1: Itanium® Architecture-based Operating System
Interaction Model with IA-32 Applications 2:267 section "10.7 I/O Port
Space Model" which describes how they can map 4 "legacy" IO ports on a
virtual page when operating in a "sparse" mode.

*). Page 378 of the ACPI6.1 specification Table 6-213 I/O Resource Flag
(Resource Type = 1) Definitions describes how a "sparse" translation can
exist depending upon bit _TRS. This seems to be implemented in Linux
using the ACPI_SPARSE_TRANSLATION types.

> It would be ideal to find
> some way to handle ia64 and ARM64 similarly.  At the very least, we
> have to make sure that this doesn't break ia64.  The ia64 dense/sparse
> I/O spaces complicate things; I don't know if ARM64 has something
> similar or not.

There's nothing directly similar - it's just regular MMIO.

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop

Re: [PATCH V6 05/13] acpi, pci: Support IO resources when parsing PCI host bridge resources.

[Jon Masters]

On 04/26/2016 10:39 PM, Bjorn Helgaas wrote:
> On Fri, Apr 15, 2016 at 07:06:40PM +0200, Tomasz Nowicki wrote:
>> Platforms that have memory mapped IO port (such as ARM64) need special
>> handling for PCI I/O resources. For host bridge's resource probing case
>> these resources need to be fixed up with 
>> pci_register_io_range/pci_remap_iospace etc.
> 
> ia64 also has memory-mapped I/O port space.

The specific references of interest to anyone here are:

*). Volume 2, Part 1: Itanium® Architecture-based Operating System
Interaction Model with IA-32 Applications 2:267 section "10.7 I/O Port
Space Model" which describes how they can map 4 "legacy" IO ports on a
virtual page when operating in a "sparse" mode.

*). Page 378 of the ACPI6.1 specification Table 6-213 I/O Resource Flag
(Resource Type = 1) Definitions describes how a "sparse" translation can
exist depending upon bit _TRS. This seems to be implemented in Linux
using the ACPI_SPARSE_TRANSLATION types.

> It would be ideal to find
> some way to handle ia64 and ARM64 similarly.  At the very least, we
> have to make sure that this doesn't break ia64.  The ia64 dense/sparse
> I/O spaces complicate things; I don't know if ARM64 has something
> similar or not.

There's nothing directly similar - it's just regular MMIO.

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop

Re: [RESEND PATCH v2 5/7] usb: xhci: plat: Remove checks for optional clock in error/remove path

[Felipe Balbi]

Jisheng Zhang  writes:
> Commit 63589e92c2d9 ("clk: Ignore error and NULL pointers passed to
> clk_{unprepare, disable}()") allows NULL or error pointer to be passed
> unconditionally.
>
> This patch is to simplify probe error and remove code paths.

this seems wrong to me. xhci->clk isn't initialized to NULL, it's either
initialized to a valid struct clk * or some ERR_PTR() value.

Care to explain ?

> Signed-off-by: Jisheng Zhang 
> ---
>  drivers/usb/host/xhci-plat.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 0e69712..83669d0 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -266,8 +266,7 @@ put_usb3_hcd:
>   usb_put_hcd(xhci->shared_hcd);
>  
>  disable_clk:
> - if (!IS_ERR(clk))
> - clk_disable_unprepare(clk);
> + clk_disable_unprepare(clk);
>  
>  put_hcd:
>   usb_put_hcd(hcd);
> @@ -287,8 +286,7 @@ static int xhci_plat_remove(struct platform_device *dev)
>   usb_remove_hcd(hcd);
>   usb_put_hcd(xhci->shared_hcd);
>  
> - if (!IS_ERR(clk))
> - clk_disable_unprepare(clk);
> + clk_disable_unprepare(clk);
>   usb_put_hcd(hcd);
>  
>   return 0;
> -- 
> 2.8.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
balbi


signature.asc
Description: PGP signature

Re: [RESEND PATCH v2 5/7] usb: xhci: plat: Remove checks for optional clock in error/remove path

[Felipe Balbi]

Jisheng Zhang  writes:
> Commit 63589e92c2d9 ("clk: Ignore error and NULL pointers passed to
> clk_{unprepare, disable}()") allows NULL or error pointer to be passed
> unconditionally.
>
> This patch is to simplify probe error and remove code paths.

this seems wrong to me. xhci->clk isn't initialized to NULL, it's either
initialized to a valid struct clk * or some ERR_PTR() value.

Care to explain ?

> Signed-off-by: Jisheng Zhang 
> ---
>  drivers/usb/host/xhci-plat.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 0e69712..83669d0 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -266,8 +266,7 @@ put_usb3_hcd:
>   usb_put_hcd(xhci->shared_hcd);
>  
>  disable_clk:
> - if (!IS_ERR(clk))
> - clk_disable_unprepare(clk);
> + clk_disable_unprepare(clk);
>  
>  put_hcd:
>   usb_put_hcd(hcd);
> @@ -287,8 +286,7 @@ static int xhci_plat_remove(struct platform_device *dev)
>   usb_remove_hcd(hcd);
>   usb_put_hcd(xhci->shared_hcd);
>  
> - if (!IS_ERR(clk))
> - clk_disable_unprepare(clk);
> + clk_disable_unprepare(clk);
>   usb_put_hcd(hcd);
>  
>   return 0;
> -- 
> 2.8.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
balbi


signature.asc
Description: PGP signature

Re: [RFC] a corner case of open(2)

[Al Viro]

Fun bugs caught while trying to massage atomic_open()...  Patch below is
in vfs.git#for-linus (along with two more fixes); I would like to get
an ACK from Miklos on that one - it's his code and this thing had been
present in there since the original merge.  I might be misreading what
it tries to do, but
open("/mnt/no-such-file", O_CREAT | O_TRUNC);
perror("open"); errno = 0;
stat("/mnt/no-such-file", );
perror("stat"); errno = 0;
open("/mnt/no-such-file", O_CREAT | O_TRUNC);
perror("open");
should *not* end up with
open: Read-only file system
stat: No such file or directory
open: No such file or directory
no matter what.  And it's very easy to arrange just that - mount nfs4
read-only on /mnt and run the snippet above.  First open() will fail with
EROFS (as it should), but as soon as the thing is in dcache we start getting
ENOENT.  Obviously bogus.

commit 1aa57f2aaa108ead7d81481af68085b0a77708f1
Author: Al Viro 
Date:   Wed Apr 27 01:11:55 2016 -0400

atomic_open(): fix the handling of create_error

* if we have a hashed negative dentry and either CREAT|EXCL on
r/o filesystem, or CREAT|TRUNC on r/o filesystem, or CREAT|EXCL
with failing may_o_create(), we should fail with EROFS or the
error may_o_create() has returned, but not ENOENT.  Which is what
the current code ends up returning.

* if we have CREAT|TRUNC hitting a regular file on a read-only
filesystem, we can't fail with EROFS here.  At the very least,
not until we'd done follow_managed() - we might have a writable
file (or a device, for that matter) bound on top of that one.
Moreover, the code downstream will see that O_TRUNC and attempt
to grab the write access (*after* following possible mount), so
if we really should fail with EROFS, it will happen.  No need
to do that inside atomic_open().

The real logics is much simpler than what the current code is
trying to do - if we decided to go for simple lookup, ended
up with a negative dentry *and* had create_error set, fail with
create_error.  No matter whether we'd got that negative dentry
from lookup_real() or had found it in dcache.

Cc: sta...@vger.kernel.org # v3.6+
Signed-off-by: Al Viro 

diff --git a/fs/namei.c b/fs/namei.c
index 1d9ca2d..b458992 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2942,22 +2942,10 @@ no_open:
dentry = lookup_real(dir, dentry, nd->flags);
if (IS_ERR(dentry))
return PTR_ERR(dentry);
-
-   if (create_error) {
-   int open_flag = op->open_flag;
-
-   error = create_error;
-   if ((open_flag & O_EXCL)) {
-   if (!dentry->d_inode)
-   goto out;
-   } else if (!dentry->d_inode) {
-   goto out;
-   } else if ((open_flag & O_TRUNC) &&
-  d_is_reg(dentry)) {
-   goto out;
-   }
-   /* will fail later, go on to get the right error */
-   }
+   }
+   if (create_error && !dentry->d_inode) {
+   error = create_error;
+   goto out;
}
 looked_up:
path->dentry = dentry;

Re: [RFC] a corner case of open(2)

[Al Viro]

Fun bugs caught while trying to massage atomic_open()...  Patch below is
in vfs.git#for-linus (along with two more fixes); I would like to get
an ACK from Miklos on that one - it's his code and this thing had been
present in there since the original merge.  I might be misreading what
it tries to do, but
open("/mnt/no-such-file", O_CREAT | O_TRUNC);
perror("open"); errno = 0;
stat("/mnt/no-such-file", );
perror("stat"); errno = 0;
open("/mnt/no-such-file", O_CREAT | O_TRUNC);
perror("open");
should *not* end up with
open: Read-only file system
stat: No such file or directory
open: No such file or directory
no matter what.  And it's very easy to arrange just that - mount nfs4
read-only on /mnt and run the snippet above.  First open() will fail with
EROFS (as it should), but as soon as the thing is in dcache we start getting
ENOENT.  Obviously bogus.

commit 1aa57f2aaa108ead7d81481af68085b0a77708f1
Author: Al Viro 
Date:   Wed Apr 27 01:11:55 2016 -0400

atomic_open(): fix the handling of create_error

* if we have a hashed negative dentry and either CREAT|EXCL on
r/o filesystem, or CREAT|TRUNC on r/o filesystem, or CREAT|EXCL
with failing may_o_create(), we should fail with EROFS or the
error may_o_create() has returned, but not ENOENT.  Which is what
the current code ends up returning.

* if we have CREAT|TRUNC hitting a regular file on a read-only
filesystem, we can't fail with EROFS here.  At the very least,
not until we'd done follow_managed() - we might have a writable
file (or a device, for that matter) bound on top of that one.
Moreover, the code downstream will see that O_TRUNC and attempt
to grab the write access (*after* following possible mount), so
if we really should fail with EROFS, it will happen.  No need
to do that inside atomic_open().

The real logics is much simpler than what the current code is
trying to do - if we decided to go for simple lookup, ended
up with a negative dentry *and* had create_error set, fail with
create_error.  No matter whether we'd got that negative dentry
from lookup_real() or had found it in dcache.

Cc: sta...@vger.kernel.org # v3.6+
Signed-off-by: Al Viro 

diff --git a/fs/namei.c b/fs/namei.c
index 1d9ca2d..b458992 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2942,22 +2942,10 @@ no_open:
dentry = lookup_real(dir, dentry, nd->flags);
if (IS_ERR(dentry))
return PTR_ERR(dentry);
-
-   if (create_error) {
-   int open_flag = op->open_flag;
-
-   error = create_error;
-   if ((open_flag & O_EXCL)) {
-   if (!dentry->d_inode)
-   goto out;
-   } else if (!dentry->d_inode) {
-   goto out;
-   } else if ((open_flag & O_TRUNC) &&
-  d_is_reg(dentry)) {
-   goto out;
-   }
-   /* will fail later, go on to get the right error */
-   }
+   }
+   if (create_error && !dentry->d_inode) {
+   error = create_error;
+   goto out;
}
 looked_up:
path->dentry = dentry;

Re: [RESEND PATCH v2 3/7] usb: xhci: plat: Fix suspend/resume when the optional usb_phy exists

[Felipe Balbi]

Hi,

Jisheng Zhang  writes:
> Commit 7b8ef22ea547 ("usb: xhci: plat: Add USB phy support") adds the
> usb_phy for usb3, but it forgets to shutdown/init the usb_phy in the
> suspend/resume path. This patch fixes this issue by adding missing
> usb_phy related calls.

Fixes: 7b8ef22ea547 ("usb: xhci: plat: Add USB phy support")
Cc:  # v4.1+

> Signed-off-by: Jisheng Zhang 
> ---
>  drivers/usb/host/xhci-plat.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 9ff89e9..fbd23fd 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -313,6 +313,7 @@ static int xhci_plat_suspend(struct device *dev)
>   if (ret)
>   return ret;
>  
> + usb_phy_shutdown(xhci->shared_hcd->usb_phy);
>   clk_disable_unprepare(xhci->clk);
>  
>   return ret;
> @@ -328,6 +329,10 @@ static int xhci_plat_resume(struct device *dev)
>   if (ret)
>   return ret;
>  
> + ret = usb_phy_init(xhci->shared_hcd->usb_phy);
> + if (ret)
> + return ret;
> +
>   return xhci_resume(xhci, 0);
>  }

-- 
balbi


signature.asc
Description: PGP signature

Re: [RESEND PATCH v2 3/7] usb: xhci: plat: Fix suspend/resume when the optional usb_phy exists

[Felipe Balbi]

Hi,

Jisheng Zhang  writes:
> Commit 7b8ef22ea547 ("usb: xhci: plat: Add USB phy support") adds the
> usb_phy for usb3, but it forgets to shutdown/init the usb_phy in the
> suspend/resume path. This patch fixes this issue by adding missing
> usb_phy related calls.

Fixes: 7b8ef22ea547 ("usb: xhci: plat: Add USB phy support")
Cc:  # v4.1+

> Signed-off-by: Jisheng Zhang 
> ---
>  drivers/usb/host/xhci-plat.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 9ff89e9..fbd23fd 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -313,6 +313,7 @@ static int xhci_plat_suspend(struct device *dev)
>   if (ret)
>   return ret;
>  
> + usb_phy_shutdown(xhci->shared_hcd->usb_phy);
>   clk_disable_unprepare(xhci->clk);
>  
>   return ret;
> @@ -328,6 +329,10 @@ static int xhci_plat_resume(struct device *dev)
>   if (ret)
>   return ret;
>  
> + ret = usb_phy_init(xhci->shared_hcd->usb_phy);
> + if (ret)
> + return ret;
> +
>   return xhci_resume(xhci, 0);
>  }

-- 
balbi


signature.asc
Description: PGP signature

Re: [RESEND PATCH v2 2/7] usb: xhci: plat: attach the usb_phy to the correct hcd

[Felipe Balbi]

Hi,

(Cc authors and maintainer, otherwise you're patch might be forgotten ;-)

Jisheng Zhang  writes:
> Commit 7b8ef22ea547 ("usb: xhci: plat: Add USB phy support") adds the
> usb_phy for usb3, but it attached the usb_phy to incorrect hcd. The

where did you see that's the USB3 phy ? I can't see it.

> xhci->shared_hcd is the hcd for usb3, this patch fixes this issue
> by attach the usb_phy to the xhci->shared_hcd.

Fixes: 7b8ef22ea547 ("usb: xhci: plat: Add USB phy support")
Cc:  Signed-off-by: Jisheng Zhang 
> ---
>  drivers/usb/host/xhci-plat.c | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 8cb46cb..9ff89e9 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -144,6 +144,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
>   struct resource *res;
>   struct usb_hcd  *hcd;
>   struct clk  *clk;
> + struct usb_phy  *usb_phy;
>   int ret;
>   int irq;
>  
> @@ -231,17 +232,18 @@ static int xhci_plat_probe(struct platform_device *pdev)
>   if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
>   xhci->shared_hcd->can_do_streams = 1;
>  
> - hcd->usb_phy = devm_usb_get_phy_by_phandle(>dev, "usb-phy", 0);
> - if (IS_ERR(hcd->usb_phy)) {
> - ret = PTR_ERR(hcd->usb_phy);
> + usb_phy = devm_usb_get_phy_by_phandle(>dev, "usb-phy", 0);
> + if (IS_ERR(usb_phy)) {
> + ret = PTR_ERR(usb_phy);
>   if (ret == -EPROBE_DEFER)
>   goto put_usb3_hcd;
> - hcd->usb_phy = NULL;
> + usb_phy = NULL;
>   } else {
> - ret = usb_phy_init(hcd->usb_phy);
> + ret = usb_phy_init(usb_phy);
>   if (ret)
>   goto put_usb3_hcd;
>   }
> + xhci->shared_hcd->usb_phy = usb_phy;
>  
>   ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
>   if (ret)
> @@ -258,7 +260,7 @@ dealloc_usb2_hcd:
>   usb_remove_hcd(hcd);
>  
>  disable_usb_phy:
> - usb_phy_shutdown(hcd->usb_phy);
> + usb_phy_shutdown(usb_phy);
>  
>  put_usb3_hcd:
>   usb_put_hcd(xhci->shared_hcd);
> @@ -280,7 +282,7 @@ static int xhci_plat_remove(struct platform_device *dev)
>   struct clk *clk = xhci->clk;
>  
>   usb_remove_hcd(xhci->shared_hcd);
> - usb_phy_shutdown(hcd->usb_phy);
> + usb_phy_shutdown(xhci->shared_hcd->usb_phy);
>  
>   usb_remove_hcd(hcd);
>   usb_put_hcd(xhci->shared_hcd);
> -- 
> 2.8.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
balbi


signature.asc
Description: PGP signature

Re: [RESEND PATCH v2 2/7] usb: xhci: plat: attach the usb_phy to the correct hcd

[Felipe Balbi]

Hi,

(Cc authors and maintainer, otherwise you're patch might be forgotten ;-)

Jisheng Zhang  writes:
> Commit 7b8ef22ea547 ("usb: xhci: plat: Add USB phy support") adds the
> usb_phy for usb3, but it attached the usb_phy to incorrect hcd. The

where did you see that's the USB3 phy ? I can't see it.

> xhci->shared_hcd is the hcd for usb3, this patch fixes this issue
> by attach the usb_phy to the xhci->shared_hcd.

Fixes: 7b8ef22ea547 ("usb: xhci: plat: Add USB phy support")
Cc:  Signed-off-by: Jisheng Zhang 
> ---
>  drivers/usb/host/xhci-plat.c | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 8cb46cb..9ff89e9 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -144,6 +144,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
>   struct resource *res;
>   struct usb_hcd  *hcd;
>   struct clk  *clk;
> + struct usb_phy  *usb_phy;
>   int ret;
>   int irq;
>  
> @@ -231,17 +232,18 @@ static int xhci_plat_probe(struct platform_device *pdev)
>   if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
>   xhci->shared_hcd->can_do_streams = 1;
>  
> - hcd->usb_phy = devm_usb_get_phy_by_phandle(>dev, "usb-phy", 0);
> - if (IS_ERR(hcd->usb_phy)) {
> - ret = PTR_ERR(hcd->usb_phy);
> + usb_phy = devm_usb_get_phy_by_phandle(>dev, "usb-phy", 0);
> + if (IS_ERR(usb_phy)) {
> + ret = PTR_ERR(usb_phy);
>   if (ret == -EPROBE_DEFER)
>   goto put_usb3_hcd;
> - hcd->usb_phy = NULL;
> + usb_phy = NULL;
>   } else {
> - ret = usb_phy_init(hcd->usb_phy);
> + ret = usb_phy_init(usb_phy);
>   if (ret)
>   goto put_usb3_hcd;
>   }
> + xhci->shared_hcd->usb_phy = usb_phy;
>  
>   ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
>   if (ret)
> @@ -258,7 +260,7 @@ dealloc_usb2_hcd:
>   usb_remove_hcd(hcd);
>  
>  disable_usb_phy:
> - usb_phy_shutdown(hcd->usb_phy);
> + usb_phy_shutdown(usb_phy);
>  
>  put_usb3_hcd:
>   usb_put_hcd(xhci->shared_hcd);
> @@ -280,7 +282,7 @@ static int xhci_plat_remove(struct platform_device *dev)
>   struct clk *clk = xhci->clk;
>  
>   usb_remove_hcd(xhci->shared_hcd);
> - usb_phy_shutdown(hcd->usb_phy);
> + usb_phy_shutdown(xhci->shared_hcd->usb_phy);
>  
>   usb_remove_hcd(hcd);
>   usb_put_hcd(xhci->shared_hcd);
> -- 
> 2.8.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
balbi


signature.asc
Description: PGP signature

Re: [RESEND PATCH v2 1/7] usb: xhci: plat: Fix suspend/resume when the optional clk exists

[Felipe Balbi]

Hi,

(since you're fixing somebody else's commit, it's nice to Cc authors)

Jisheng Zhang  writes:
> Commit 4718c1774051 ("usb: host: xhci-plat: add clock support") adds
> optional clk support, but it forgets to prepare/disable and
  ^^^
  prepare/enable ?

> enable/unprepare the clk in the resume/suspend path. This path fixes
    
  disable/unprepare ?   patch

> this issue by adding missing clk related calls.

frankly, I'm not sure this patch is entirely correct. At minimum, it's
not necessarily a bug fix. Original commit had no intent in gating
clocks during suspend/resume and, IMHO, that might not be what *all*
XHCI implementations want, though I'm not entirely sure.

> Signed-off-by: Jisheng Zhang 
> Fixes: 4718c1774051 ("usb: host: xhci-plat: add clock support")

Assuming this is, indeed, a fix; you need to Cc stable here. Just add:

Cc:  # v3.16+

> ---
>  drivers/usb/host/xhci-plat.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 474b5fa..8cb46cb 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -295,6 +295,7 @@ static int xhci_plat_remove(struct platform_device *dev)
>  #ifdef CONFIG_PM_SLEEP
>  static int xhci_plat_suspend(struct device *dev)
>  {
> + int ret;

this would look neater after hcd and xhci declarations below

>   struct usb_hcd  *hcd = dev_get_drvdata(dev);
>   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
>  
> @@ -306,14 +307,25 @@ static int xhci_plat_suspend(struct device *dev)
>* reconsider this when xhci_plat_suspend enlarges its scope, e.g.,
>* also applies to runtime suspend.
>*/
> - return xhci_suspend(xhci, device_may_wakeup(dev));
> + ret = xhci_suspend(xhci, device_may_wakeup(dev));
> + if (ret)
> + return ret;
> +
> + clk_disable_unprepare(xhci->clk);
> +
> + return ret;
>  }
>  
>  static int xhci_plat_resume(struct device *dev)
>  {
> + int ret;

ditto

>   struct usb_hcd  *hcd = dev_get_drvdata(dev);
>   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
>  
> + ret = clk_prepare_enable(xhci->clk);
> + if (ret)
> + return ret;
> +
>   return xhci_resume(xhci, 0);
>  }
>  
> -- 
> 2.8.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
balbi


signature.asc
Description: PGP signature

Re: [RESEND PATCH v2 1/7] usb: xhci: plat: Fix suspend/resume when the optional clk exists

[Felipe Balbi]

Hi,

(since you're fixing somebody else's commit, it's nice to Cc authors)

Jisheng Zhang  writes:
> Commit 4718c1774051 ("usb: host: xhci-plat: add clock support") adds
> optional clk support, but it forgets to prepare/disable and
  ^^^
  prepare/enable ?

> enable/unprepare the clk in the resume/suspend path. This path fixes
    
  disable/unprepare ?   patch

> this issue by adding missing clk related calls.

frankly, I'm not sure this patch is entirely correct. At minimum, it's
not necessarily a bug fix. Original commit had no intent in gating
clocks during suspend/resume and, IMHO, that might not be what *all*
XHCI implementations want, though I'm not entirely sure.

> Signed-off-by: Jisheng Zhang 
> Fixes: 4718c1774051 ("usb: host: xhci-plat: add clock support")

Assuming this is, indeed, a fix; you need to Cc stable here. Just add:

Cc:  # v3.16+

> ---
>  drivers/usb/host/xhci-plat.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 474b5fa..8cb46cb 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -295,6 +295,7 @@ static int xhci_plat_remove(struct platform_device *dev)
>  #ifdef CONFIG_PM_SLEEP
>  static int xhci_plat_suspend(struct device *dev)
>  {
> + int ret;

this would look neater after hcd and xhci declarations below

>   struct usb_hcd  *hcd = dev_get_drvdata(dev);
>   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
>  
> @@ -306,14 +307,25 @@ static int xhci_plat_suspend(struct device *dev)
>* reconsider this when xhci_plat_suspend enlarges its scope, e.g.,
>* also applies to runtime suspend.
>*/
> - return xhci_suspend(xhci, device_may_wakeup(dev));
> + ret = xhci_suspend(xhci, device_may_wakeup(dev));
> + if (ret)
> + return ret;
> +
> + clk_disable_unprepare(xhci->clk);
> +
> + return ret;
>  }
>  
>  static int xhci_plat_resume(struct device *dev)
>  {
> + int ret;

ditto

>   struct usb_hcd  *hcd = dev_get_drvdata(dev);
>   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
>  
> + ret = clk_prepare_enable(xhci->clk);
> + if (ret)
> + return ret;
> +
>   return xhci_resume(xhci, 0);
>  }
>  
> -- 
> 2.8.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH V2 1/2] devicetree/bindings: Add binding for operator panel on FSP machines

[Stewart Smith]

Suraj Jitindar Singh  writes:
> Add a binding to Documentation/devicetree/bindings/powerpc/opal
> (oppanel-opal.txt) for the operator panel which is present on IBM
> pseries machines with FSPs.

It's not pseries (as that implies PowerVM / PAPR) - while here we're all
about OPAL.

With a slight change to the commit message,
Acked-by: Stewart Smith 


-- 
Stewart Smith
OPAL Architect, IBM.

Re: [PATCH V2 1/2] devicetree/bindings: Add binding for operator panel on FSP machines

[Stewart Smith]

Suraj Jitindar Singh  writes:
> Add a binding to Documentation/devicetree/bindings/powerpc/opal
> (oppanel-opal.txt) for the operator panel which is present on IBM
> pseries machines with FSPs.

It's not pseries (as that implies PowerVM / PAPR) - while here we're all
about OPAL.

With a slight change to the commit message,
Acked-by: Stewart Smith 


-- 
Stewart Smith
OPAL Architect, IBM.

Re: [PATCH] xen/x86: actually allocate legacy interrupts on PV guests

[Juergen Gross]

On 21/04/16 11:30, Stefano Stabellini wrote:
> On Thu, 21 Apr 2016, Juergen Gross wrote:
>> On 20/04/16 15:15, Stefano Stabellini wrote:
>>> b4ff8389ed14 is incomplete: relies on nr_legacy_irqs() to get the number
>>> of legacy interrupts when actually nr_legacy_irqs() returns 0 after
>>> probe_8259A(). Use NR_IRQS_LEGACY instead.
>>
>> Would you mind describing the resulting problem?
> 
> This is a good question. The symptom is:
> 
> ata_piix: probe of :00:01.1 failed with error -22
> 
> 
>> With this commit message I'm absolutely not capable to decide whether
>> e.g. the other use of nr_legacy_irqs() in pci_xen_initial_domain() is
>> correct or not.
> 
> I looked at it but I couldn't really test that code because if I try to
> change the number of ioapics in the system using the "noapic" command
> line option (which actually changes the number if ioapics, not lapics),
> I get an error from Linux saying that noapic is not supported when
> running on Xen.
> 
> In my opinion having nr_legacy_irqs() calls in Xen code, which returns
> 0, is like playing with fire. I think it would be safer/saner to replace
> them all with NR_IRQS_LEGACY, simply because reading the code one would
> not expect that all those loops don't actually have any iterations.

I'm quite sure you should change both uses of nr_legacy_irqs() in
pci_xen_initial_domain().

Looking at xen_pcifront_enable_irq() I'm not really sure what is the
correct thing to do.

Adding Konrad as he might have a better insight.


Juergen

> 
> However I didn't make the change because I couldn't test it properly.
> 
> 
>>> Signed-off-by: Stefano Stabellini 
>>>
>>> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
>>> index beac4df..349b8ce 100644
>>> --- a/arch/x86/pci/xen.c
>>> +++ b/arch/x86/pci/xen.c
>>> @@ -491,8 +491,11 @@ int __init pci_xen_initial_domain(void)
>>>  #endif
>>> __acpi_register_gsi = acpi_register_gsi_xen;
>>> __acpi_unregister_gsi = NULL;
>>> -   /* Pre-allocate legacy irqs */
>>> -   for (irq = 0; irq < nr_legacy_irqs(); irq++) {
>>> +   /*
>>> +* Pre-allocate the legacy IRQs.  Use NR_LEGACY_IRQS here
>>> +* because we don't have a PIC and thus nr_legacy_irqs() is zero.
>>> +*/
>>> +   for (irq = 0; irq < NR_IRQS_LEGACY; irq++) {
>>> int trigger, polarity;
>>>  
>>> if (acpi_get_override_irq(irq, , ) == -1)
>>>
>>
> 
> 

Re: [GIT PULL] platform-drivers-x86 for 4.6-3

[Darren Hart]

On Tue, Apr 26, 2016 at 09:58:01PM -0700, Darren Hart wrote:
> Hi Linus,
> 
> The following changes since commit 5d07163334ba016c053b033cd0bb3c92d7dc0229:
> 
>   platform:x86 decouple telemetry driver from the optional IPC resources 
> (2016-04-19 13:51:41 -0700)
> 
> are available in the git repository at:
> 
>   git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git 
> tags/platform-drivers-x86-v4.6-3
> 
> for you to fetch changes up to a30b8f81d9d6fe24eab8a023794548b048f08e3c:
> 
>   toshiba_acpi: Fix regression caused by hotkey enabling value (2016-04-25 
> 10:31:59 -0700)

Linus,

Found myself not wanting to send a one patch pull request, but not wanting to
wait until RC6 and possibly miss 4.6.

Do you have a preference during the RC cycle in terms of balance between patch
count and frequency for a small subsystem like platform-driver-x86?

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH] xen/x86: actually allocate legacy interrupts on PV guests

[Juergen Gross]

On 21/04/16 11:30, Stefano Stabellini wrote:
> On Thu, 21 Apr 2016, Juergen Gross wrote:
>> On 20/04/16 15:15, Stefano Stabellini wrote:
>>> b4ff8389ed14 is incomplete: relies on nr_legacy_irqs() to get the number
>>> of legacy interrupts when actually nr_legacy_irqs() returns 0 after
>>> probe_8259A(). Use NR_IRQS_LEGACY instead.
>>
>> Would you mind describing the resulting problem?
> 
> This is a good question. The symptom is:
> 
> ata_piix: probe of :00:01.1 failed with error -22
> 
> 
>> With this commit message I'm absolutely not capable to decide whether
>> e.g. the other use of nr_legacy_irqs() in pci_xen_initial_domain() is
>> correct or not.
> 
> I looked at it but I couldn't really test that code because if I try to
> change the number of ioapics in the system using the "noapic" command
> line option (which actually changes the number if ioapics, not lapics),
> I get an error from Linux saying that noapic is not supported when
> running on Xen.
> 
> In my opinion having nr_legacy_irqs() calls in Xen code, which returns
> 0, is like playing with fire. I think it would be safer/saner to replace
> them all with NR_IRQS_LEGACY, simply because reading the code one would
> not expect that all those loops don't actually have any iterations.

I'm quite sure you should change both uses of nr_legacy_irqs() in
pci_xen_initial_domain().

Looking at xen_pcifront_enable_irq() I'm not really sure what is the
correct thing to do.

Adding Konrad as he might have a better insight.


Juergen

> 
> However I didn't make the change because I couldn't test it properly.
> 
> 
>>> Signed-off-by: Stefano Stabellini 
>>>
>>> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
>>> index beac4df..349b8ce 100644
>>> --- a/arch/x86/pci/xen.c
>>> +++ b/arch/x86/pci/xen.c
>>> @@ -491,8 +491,11 @@ int __init pci_xen_initial_domain(void)
>>>  #endif
>>> __acpi_register_gsi = acpi_register_gsi_xen;
>>> __acpi_unregister_gsi = NULL;
>>> -   /* Pre-allocate legacy irqs */
>>> -   for (irq = 0; irq < nr_legacy_irqs(); irq++) {
>>> +   /*
>>> +* Pre-allocate the legacy IRQs.  Use NR_LEGACY_IRQS here
>>> +* because we don't have a PIC and thus nr_legacy_irqs() is zero.
>>> +*/
>>> +   for (irq = 0; irq < NR_IRQS_LEGACY; irq++) {
>>> int trigger, polarity;
>>>  
>>> if (acpi_get_override_irq(irq, , ) == -1)
>>>
>>
> 
> 

Re: [GIT PULL] platform-drivers-x86 for 4.6-3

[Darren Hart]

On Tue, Apr 26, 2016 at 09:58:01PM -0700, Darren Hart wrote:
> Hi Linus,
> 
> The following changes since commit 5d07163334ba016c053b033cd0bb3c92d7dc0229:
> 
>   platform:x86 decouple telemetry driver from the optional IPC resources 
> (2016-04-19 13:51:41 -0700)
> 
> are available in the git repository at:
> 
>   git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git 
> tags/platform-drivers-x86-v4.6-3
> 
> for you to fetch changes up to a30b8f81d9d6fe24eab8a023794548b048f08e3c:
> 
>   toshiba_acpi: Fix regression caused by hotkey enabling value (2016-04-25 
> 10:31:59 -0700)

Linus,

Found myself not wanting to send a one patch pull request, but not wanting to
wait until RC6 and possibly miss 4.6.

Do you have a preference during the RC cycle in terms of balance between patch
count and frequency for a small subsystem like platform-driver-x86?

-- 
Darren Hart
Intel Open Source Technology Center

[GIT PULL] platform-drivers-x86 for 4.6-3

[Darren Hart]

Hi Linus,

The following changes since commit 5d07163334ba016c053b033cd0bb3c92d7dc0229:

  platform:x86 decouple telemetry driver from the optional IPC resources 
(2016-04-19 13:51:41 -0700)

are available in the git repository at:

  git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git 
tags/platform-drivers-x86-v4.6-3

for you to fetch changes up to a30b8f81d9d6fe24eab8a023794548b048f08e3c:

  toshiba_acpi: Fix regression caused by hotkey enabling value (2016-04-25 
10:31:59 -0700)


platform-drivers-x86 for 4.6-3

toshiba_acpi:
 - Fix regression caused by hotkey enabling value


Azael Avalos (1):
  toshiba_acpi: Fix regression caused by hotkey enabling value

 drivers/platform/x86/toshiba_acpi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
Darren Hart
Intel Open Source Technology Center

[GIT PULL] platform-drivers-x86 for 4.6-3

[Darren Hart]

Hi Linus,

The following changes since commit 5d07163334ba016c053b033cd0bb3c92d7dc0229:

  platform:x86 decouple telemetry driver from the optional IPC resources 
(2016-04-19 13:51:41 -0700)

are available in the git repository at:

  git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git 
tags/platform-drivers-x86-v4.6-3

for you to fetch changes up to a30b8f81d9d6fe24eab8a023794548b048f08e3c:

  toshiba_acpi: Fix regression caused by hotkey enabling value (2016-04-25 
10:31:59 -0700)


platform-drivers-x86 for 4.6-3

toshiba_acpi:
 - Fix regression caused by hotkey enabling value


Azael Avalos (1):
  toshiba_acpi: Fix regression caused by hotkey enabling value

 drivers/platform/x86/toshiba_acpi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
Darren Hart
Intel Open Source Technology Center

linux-next: manual merge of the staging tree with the staging.current tree

[Stephen Rothwell]

Hi Greg,

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

  drivers/iio/magnetometer/ak8975.c

between commit:

  05be8d4101d9 ("iio: ak8975: fix maybe-uninitialized warning")

from the staging.current tree and commit:

  97eacb9166f4 ("iio:ak8975: add mounting matrix support")

from the staging tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/iio/magnetometer/ak8975.c
index 0e931a9a1669,dbf066129a04..
--- a/drivers/iio/magnetometer/ak8975.c
+++ b/drivers/iio/magnetometer/ak8975.c
@@@ -732,11 -851,13 +851,13 @@@ static int ak8975_probe(struct i2c_clie
int eoc_gpio;
int err;
const char *name = NULL;
 -  enum asahi_compass_chipset chipset;
 +  enum asahi_compass_chipset chipset = AK_MAX_TYPE;
+   const struct ak8975_platform_data *pdata =
+   dev_get_platdata(>dev);
  
/* Grab and set up the supplied GPIO. */
-   if (client->dev.platform_data)
-   eoc_gpio = *(int *)(client->dev.platform_data);
+   if (pdata)
+   eoc_gpio = pdata->eoc_gpio;
else if (client->dev.of_node)
eoc_gpio = of_get_gpio(client->dev.of_node, 0);
else

linux-next: manual merge of the staging tree with the staging.current tree

[Stephen Rothwell]

Hi Greg,

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

  drivers/iio/magnetometer/ak8975.c

between commit:

  05be8d4101d9 ("iio: ak8975: fix maybe-uninitialized warning")

from the staging.current tree and commit:

  97eacb9166f4 ("iio:ak8975: add mounting matrix support")

from the staging tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/iio/magnetometer/ak8975.c
index 0e931a9a1669,dbf066129a04..
--- a/drivers/iio/magnetometer/ak8975.c
+++ b/drivers/iio/magnetometer/ak8975.c
@@@ -732,11 -851,13 +851,13 @@@ static int ak8975_probe(struct i2c_clie
int eoc_gpio;
int err;
const char *name = NULL;
 -  enum asahi_compass_chipset chipset;
 +  enum asahi_compass_chipset chipset = AK_MAX_TYPE;
+   const struct ak8975_platform_data *pdata =
+   dev_get_platdata(>dev);
  
/* Grab and set up the supplied GPIO. */
-   if (client->dev.platform_data)
-   eoc_gpio = *(int *)(client->dev.platform_data);
+   if (pdata)
+   eoc_gpio = pdata->eoc_gpio;
else if (client->dev.of_node)
eoc_gpio = of_get_gpio(client->dev.of_node, 0);
else

Re: [PATCH 1/6] bus: Add shared MDIO bus framework

[Anup Patel]

On Wed, Apr 27, 2016 at 1:11 AM, Andrew Lunn  wrote:
> On Tue, Apr 26, 2016 at 09:24:34PM +0200, Arnd Bergmann wrote:
>> On Tuesday 26 April 2016 20:23:35 Andrew Lunn wrote:
>> > > A more complex problem would be having a PHY driver for a device
>> > > that can be either an ethernet phy or some other phy.
>> >
>> > I doubt that ever happens. You can have up to 32 different devices on
>> > an MDIO bus. Since an Ethernet PHY and a "some other sort of PHY" are
>> > completely different things, why would a hardware engineer place them
>> > on the same address? It is like saying your ATA controller and VGA
>> > controller share the same slot on the PCI bus...
>>
>> To clarify: what I meant is a device that is designed as a PHY for
>> similar hardware (e.g. SATA, USB3 and PCIe) and that has a common
>> register set and a single driver, but that driver can operate
>> in multiple modes. You typically have multiple instances of
>> such hardware, with each instance linked to exactly one host
>> device, but one driver for all of them.
>>
>> See Documentation/devicetree/bindings/phy/apm-xgene-phy.txt
>> and drivers/phy/phy-xgene.c for one such example.
>
> Interesting. Also, that this lists SGMII. I assume this is a phy in
> the MAC in order to talk to the Ethernet PHY.
>
> I still don't see it being a big problem if a phy driver implements an
> Ethernet PHY. It just needs to call phy_device_create() and
> phy_device_register().
>
> Andrew

It is really interesting to see the evolution of MDIO bus:

1. Traditionally, MDIO controller used to be part of each ethernet controller
itself so each ethernet controller used to have it's own 2 wire MDIO bus

2. Next, we saw SoC with multiple ethernet controllers sharing same MDIO
bus. In other words, we saw multiple MDIO bus being muxed over single
MDIO bus with additional bus select lines (I think this is when
drivers/net/phy/mdio-mux.c APIs were implemented but at this point all
PHYs on muxed MDIO bus were ethernet PHYs).

3. Then, we saw SoC with ethernet switch devices also accessible over
shared MDIO bus (or Muxed MDIO bus) along with ethernet PHYs (I guess
this is why we have drivers/net/phy/mdio_device.c which adds
"mdio_device" for non-ethernet-PHY devices on MDIO bus).

4. Now, we have SoC with SATA PHYs, PCIe PHYs, USB PHYs, and Ethernet
PHYs all accessible over same shared MDIO bus (or Muxed MDIO bus). The
SATA PHYs and PCIe PHYs are registered to "Generic PHY framework". For
USB PHYs, we can either register to "Generic PHY framework" or "USB PHY
framework". For Ethernet PHYs, we register MDIO bus instance to "Ethernet
MDIO framework".

The devices on ARM64 SoC has to be within first 4GB and RAM has to start
from first 4GB to be ARM compliant because ARM64 CPUs have 32bit mode and
all devices and RAM should be available to 32bit mode with MMU disabled.
This means that we only have 4GB to fit all devices registers and some
portion of RAM. Some of these non-Ethernet PHYs have tons of registers so
as number of PHYs increase in a SoC they will eat-up lot of first 4GB
address space. Using same MDIO bus for all types of PHYs (SATA, PCIe, USB,
and Ethernet) is actually a good approach because it actually saves lot of
first 4GB address space. In future, more devices will be moved to a shared
MDIO bus which are less frequently accessed.

For Broadcom iProc SoCs, the design choice has already been made to use
shared MDIO bus for all PHYs. In fact, Broadcom iProc NS2 SoC already has
a shared MDIO bus for SATA PHYs, USB PHYs, PCIe PHYs, and Ethernet
PHYs and more Broadcom iProc SoCs are on their way. Of course, there are
few exceptions in iProc SoCs such as SATA PHYs where we also have memory
mapped registers to access PHYs but other PHYs don't have such memory
mapped registers.

Clearly from above, the traditional 2 wire MDIO bus is now a shared MDIO
bus with 2-wire plus additional select lines. Also, now we have SoCs (such
as Broadcom iProc SoCs) which has such shared MDIO bus and I think
in-future we will have SoCs with a shared MDIO bus for variety of devices.

For long term, we really need a clean solution to fit shared MDIO based
PHY drivers in Linux kernel. Also, shared MDIO based PHY drivers should
not be dependent on any particular IO subsystem (such as Linux Ethernet)
because there are lot of use-cases where people want strip down kernel
image by not-compiling IO subsystems which are not required.

IMHO, we have several options in front of us:
1. Use some light-weight framework (such as shared_mdio.c implemented
by this patchset) under drivers/bus
2. Extend "Generic PHY framework" to allow something like shared MDIO
bus (as-per Arnd's suggestion)
3. Move-out "MDIO-mux APIs" from drivers/net/phy to something like
drivers/mdio-mux and make it independent of "Linux Ethernet subsystem".
(... may be more options ...)

Regards,
Anup

Re: [PATCH 1/6] bus: Add shared MDIO bus framework

[Anup Patel]

On Wed, Apr 27, 2016 at 1:11 AM, Andrew Lunn  wrote:
> On Tue, Apr 26, 2016 at 09:24:34PM +0200, Arnd Bergmann wrote:
>> On Tuesday 26 April 2016 20:23:35 Andrew Lunn wrote:
>> > > A more complex problem would be having a PHY driver for a device
>> > > that can be either an ethernet phy or some other phy.
>> >
>> > I doubt that ever happens. You can have up to 32 different devices on
>> > an MDIO bus. Since an Ethernet PHY and a "some other sort of PHY" are
>> > completely different things, why would a hardware engineer place them
>> > on the same address? It is like saying your ATA controller and VGA
>> > controller share the same slot on the PCI bus...
>>
>> To clarify: what I meant is a device that is designed as a PHY for
>> similar hardware (e.g. SATA, USB3 and PCIe) and that has a common
>> register set and a single driver, but that driver can operate
>> in multiple modes. You typically have multiple instances of
>> such hardware, with each instance linked to exactly one host
>> device, but one driver for all of them.
>>
>> See Documentation/devicetree/bindings/phy/apm-xgene-phy.txt
>> and drivers/phy/phy-xgene.c for one such example.
>
> Interesting. Also, that this lists SGMII. I assume this is a phy in
> the MAC in order to talk to the Ethernet PHY.
>
> I still don't see it being a big problem if a phy driver implements an
> Ethernet PHY. It just needs to call phy_device_create() and
> phy_device_register().
>
> Andrew

It is really interesting to see the evolution of MDIO bus:

1. Traditionally, MDIO controller used to be part of each ethernet controller
itself so each ethernet controller used to have it's own 2 wire MDIO bus

2. Next, we saw SoC with multiple ethernet controllers sharing same MDIO
bus. In other words, we saw multiple MDIO bus being muxed over single
MDIO bus with additional bus select lines (I think this is when
drivers/net/phy/mdio-mux.c APIs were implemented but at this point all
PHYs on muxed MDIO bus were ethernet PHYs).

3. Then, we saw SoC with ethernet switch devices also accessible over
shared MDIO bus (or Muxed MDIO bus) along with ethernet PHYs (I guess
this is why we have drivers/net/phy/mdio_device.c which adds
"mdio_device" for non-ethernet-PHY devices on MDIO bus).

4. Now, we have SoC with SATA PHYs, PCIe PHYs, USB PHYs, and Ethernet
PHYs all accessible over same shared MDIO bus (or Muxed MDIO bus). The
SATA PHYs and PCIe PHYs are registered to "Generic PHY framework". For
USB PHYs, we can either register to "Generic PHY framework" or "USB PHY
framework". For Ethernet PHYs, we register MDIO bus instance to "Ethernet
MDIO framework".

The devices on ARM64 SoC has to be within first 4GB and RAM has to start
from first 4GB to be ARM compliant because ARM64 CPUs have 32bit mode and
all devices and RAM should be available to 32bit mode with MMU disabled.
This means that we only have 4GB to fit all devices registers and some
portion of RAM. Some of these non-Ethernet PHYs have tons of registers so
as number of PHYs increase in a SoC they will eat-up lot of first 4GB
address space. Using same MDIO bus for all types of PHYs (SATA, PCIe, USB,
and Ethernet) is actually a good approach because it actually saves lot of
first 4GB address space. In future, more devices will be moved to a shared
MDIO bus which are less frequently accessed.

For Broadcom iProc SoCs, the design choice has already been made to use
shared MDIO bus for all PHYs. In fact, Broadcom iProc NS2 SoC already has
a shared MDIO bus for SATA PHYs, USB PHYs, PCIe PHYs, and Ethernet
PHYs and more Broadcom iProc SoCs are on their way. Of course, there are
few exceptions in iProc SoCs such as SATA PHYs where we also have memory
mapped registers to access PHYs but other PHYs don't have such memory
mapped registers.

Clearly from above, the traditional 2 wire MDIO bus is now a shared MDIO
bus with 2-wire plus additional select lines. Also, now we have SoCs (such
as Broadcom iProc SoCs) which has such shared MDIO bus and I think
in-future we will have SoCs with a shared MDIO bus for variety of devices.

For long term, we really need a clean solution to fit shared MDIO based
PHY drivers in Linux kernel. Also, shared MDIO based PHY drivers should
not be dependent on any particular IO subsystem (such as Linux Ethernet)
because there are lot of use-cases where people want strip down kernel
image by not-compiling IO subsystems which are not required.

IMHO, we have several options in front of us:
1. Use some light-weight framework (such as shared_mdio.c implemented
by this patchset) under drivers/bus
2. Extend "Generic PHY framework" to allow something like shared MDIO
bus (as-per Arnd's suggestion)
3. Move-out "MDIO-mux APIs" from drivers/net/phy to something like
drivers/mdio-mux and make it independent of "Linux Ethernet subsystem".
(... may be more options ...)

Regards,
Anup

Re: [PATCH 1/1] simplified security.nscapability xattr

[Serge E. Hallyn]

Quoting Kees Cook (keesc...@chromium.org):
> On Tue, Apr 26, 2016 at 3:26 PM, Serge E. Hallyn  wrote:
> > Quoting Kees Cook (keesc...@chromium.org):
> >> On Fri, Apr 22, 2016 at 10:26 AM,   wrote:
> >> > From: Serge Hallyn 
> >> >
> >> > This can only be set by root in his own namespace, and will
> >> > only be respected by namespaces with that same root kuid
> >> > mapped as root, or namespaces descended from it.
> >> >
> >> > This allows a simple setxattr to work, allows tar/untar to
> >> > work, and allows us to tar in one namespace and untar in
> >> > another while preserving the capability, without risking
> >> > leaking privilege into a parent namespace.
> >>
> >> The concept seems sensible to me. Various notes below...
> >>
> >> >
> >> > Signed-off-by: Serge Hallyn 
> >> > ---
> >> >  include/linux/capability.h  |5 ++-
> >> >  include/uapi/linux/capability.h |   18 
> >> >  include/uapi/linux/xattr.h  |3 ++
> >> >  security/commoncap.c|   91 
> >> > +--
> >> >  4 files changed, 112 insertions(+), 5 deletions(-)
> >> >
> >> > diff --git a/include/linux/capability.h b/include/linux/capability.h
> >> > index 00690ff..cf533ff 100644
> >> > --- a/include/linux/capability.h
> >> > +++ b/include/linux/capability.h
> >> > @@ -13,7 +13,7 @@
> >> >  #define _LINUX_CAPABILITY_H
> >> >
> >> >  #include 
> >> > -
> >> > +#include 
> >> >
> >> >  #define _KERNEL_CAPABILITY_VERSION _LINUX_CAPABILITY_VERSION_3
> >> >  #define _KERNEL_CAPABILITY_U32S_LINUX_CAPABILITY_U32S_3
> >> > @@ -31,6 +31,9 @@ struct cpu_vfs_cap_data {
> >> > kernel_cap_t inheritable;
> >> >  };
> >> >
> >> > +#define NS_CAPS_VERSION(x) (x & 0xFF)
> >> > +#define NS_CAPS_FLAGS(x) ((x >> 8) & 0xFF)
> >> > +
> >> >  #define _USER_CAP_HEADER_SIZE  (sizeof(struct __user_cap_header_struct))
> >> >  #define _KERNEL_CAP_T_SIZE (sizeof(kernel_cap_t))
> >> >
> >> > diff --git a/include/uapi/linux/capability.h 
> >> > b/include/uapi/linux/capability.h
> >> > index 12c37a1..f0b4a66 100644
> >> > --- a/include/uapi/linux/capability.h
> >> > +++ b/include/uapi/linux/capability.h
> >> > @@ -62,6 +62,9 @@ typedef struct __user_cap_data_struct {
> >> >  #define VFS_CAP_U32_2   2
> >> >  #define XATTR_CAPS_SZ_2 (sizeof(__le32)*(1 + 2*VFS_CAP_U32_2))
> >> >
> >> > +/* version number for security.nscapability xattrs hdr->hdr_info */
> >> > +#define VFS_NS_CAP_REVISION 1
> >> > +
> >> >  #define XATTR_CAPS_SZ   XATTR_CAPS_SZ_2
> >> >  #define VFS_CAP_U32 VFS_CAP_U32_2
> >> >  #define VFS_CAP_REVISION   VFS_CAP_REVISION_2
> >> > @@ -74,6 +77,21 @@ struct vfs_cap_data {
> >> > } data[VFS_CAP_U32];
> >> >  };
> >> >
> >> > +#define VFS_NS_CAP_EFFECTIVE0x1
> >> > +/*
> >> > + * 32-bit hdr_info contains
> >> > + * 16 leftmost: reserved
> >> > + * next 8: flags (only VFS_NS_CAP_EFFECTIVE so far)
> >> > + * last 8: version
> >> > + */
> >> > +struct vfs_ns_cap_data {
> >> > +   __le32 magic_etc;
> >> > +   struct {
> >> > +   __le32 permitted;/* Little endian */
> >> > +   __le32 inheritable;  /* Little endian */
> >> > +   } data[VFS_CAP_U32];
> >> > +};
> >>
> >> This is identical to vfs_cap_data. Is there a reason not to re-use the
> >> existing one?
> >
> > Hm.  I used to have them completely different.  ATM the only difference
> > is what goes into the magic_etc, and that not very (different).  So
> > yeah it probably should be re-used.
> >
> >> > +
> >> >  #ifndef __KERNEL__
> >> >
> >> >  /*
> >> > diff --git a/include/uapi/linux/xattr.h b/include/uapi/linux/xattr.h
> >> > index 1590c49..67c80ab 100644
> >> > --- a/include/uapi/linux/xattr.h
> >> > +++ b/include/uapi/linux/xattr.h
> >> > @@ -68,6 +68,9 @@
> >> >  #define XATTR_CAPS_SUFFIX "capability"
> >> >  #define XATTR_NAME_CAPS XATTR_SECURITY_PREFIX XATTR_CAPS_SUFFIX
> >> >
> >> > +#define XATTR_NS_CAPS_SUFFIX "nscapability"
> >> > +#define XATTR_NAME_NS_CAPS XATTR_SECURITY_PREFIX XATTR_NS_CAPS_SUFFIX
> >> > +
> >> >  #define XATTR_POSIX_ACL_ACCESS  "posix_acl_access"
> >> >  #define XATTR_NAME_POSIX_ACL_ACCESS XATTR_SYSTEM_PREFIX 
> >> > XATTR_POSIX_ACL_ACCESS
> >> >  #define XATTR_POSIX_ACL_DEFAULT  "posix_acl_default"
> >>
> >> Are these documented anywhere in Documentation/ or in man pages? This
> >> seems like it'd need a man-page update too.
> >
> > Yeah, if we decide we're ok with this strategy I'll update those.
> >
> >> > diff --git a/security/commoncap.c b/security/commoncap.c
> >> > index 48071ed..8f3f34a 100644
> >> > --- a/security/commoncap.c
> >> > +++ b/security/commoncap.c
> >> > @@ -313,6 +313,10 @@ int cap_inode_need_killpriv(struct dentry *dentry)
> >> > if (!inode->i_op->getxattr)
> >> >return 0;
> >> >
> >> > +   error = inode->i_op->getxattr(dentry, XATTR_NAME_NS_CAPS, NULL, 
> >> > 0);

Re: [PATCH 1/1] simplified security.nscapability xattr

[Serge E. Hallyn]

Quoting Kees Cook (keesc...@chromium.org):
> On Tue, Apr 26, 2016 at 3:26 PM, Serge E. Hallyn  wrote:
> > Quoting Kees Cook (keesc...@chromium.org):
> >> On Fri, Apr 22, 2016 at 10:26 AM,   wrote:
> >> > From: Serge Hallyn 
> >> >
> >> > This can only be set by root in his own namespace, and will
> >> > only be respected by namespaces with that same root kuid
> >> > mapped as root, or namespaces descended from it.
> >> >
> >> > This allows a simple setxattr to work, allows tar/untar to
> >> > work, and allows us to tar in one namespace and untar in
> >> > another while preserving the capability, without risking
> >> > leaking privilege into a parent namespace.
> >>
> >> The concept seems sensible to me. Various notes below...
> >>
> >> >
> >> > Signed-off-by: Serge Hallyn 
> >> > ---
> >> >  include/linux/capability.h  |5 ++-
> >> >  include/uapi/linux/capability.h |   18 
> >> >  include/uapi/linux/xattr.h  |3 ++
> >> >  security/commoncap.c|   91 
> >> > +--
> >> >  4 files changed, 112 insertions(+), 5 deletions(-)
> >> >
> >> > diff --git a/include/linux/capability.h b/include/linux/capability.h
> >> > index 00690ff..cf533ff 100644
> >> > --- a/include/linux/capability.h
> >> > +++ b/include/linux/capability.h
> >> > @@ -13,7 +13,7 @@
> >> >  #define _LINUX_CAPABILITY_H
> >> >
> >> >  #include 
> >> > -
> >> > +#include 
> >> >
> >> >  #define _KERNEL_CAPABILITY_VERSION _LINUX_CAPABILITY_VERSION_3
> >> >  #define _KERNEL_CAPABILITY_U32S_LINUX_CAPABILITY_U32S_3
> >> > @@ -31,6 +31,9 @@ struct cpu_vfs_cap_data {
> >> > kernel_cap_t inheritable;
> >> >  };
> >> >
> >> > +#define NS_CAPS_VERSION(x) (x & 0xFF)
> >> > +#define NS_CAPS_FLAGS(x) ((x >> 8) & 0xFF)
> >> > +
> >> >  #define _USER_CAP_HEADER_SIZE  (sizeof(struct __user_cap_header_struct))
> >> >  #define _KERNEL_CAP_T_SIZE (sizeof(kernel_cap_t))
> >> >
> >> > diff --git a/include/uapi/linux/capability.h 
> >> > b/include/uapi/linux/capability.h
> >> > index 12c37a1..f0b4a66 100644
> >> > --- a/include/uapi/linux/capability.h
> >> > +++ b/include/uapi/linux/capability.h
> >> > @@ -62,6 +62,9 @@ typedef struct __user_cap_data_struct {
> >> >  #define VFS_CAP_U32_2   2
> >> >  #define XATTR_CAPS_SZ_2 (sizeof(__le32)*(1 + 2*VFS_CAP_U32_2))
> >> >
> >> > +/* version number for security.nscapability xattrs hdr->hdr_info */
> >> > +#define VFS_NS_CAP_REVISION 1
> >> > +
> >> >  #define XATTR_CAPS_SZ   XATTR_CAPS_SZ_2
> >> >  #define VFS_CAP_U32 VFS_CAP_U32_2
> >> >  #define VFS_CAP_REVISION   VFS_CAP_REVISION_2
> >> > @@ -74,6 +77,21 @@ struct vfs_cap_data {
> >> > } data[VFS_CAP_U32];
> >> >  };
> >> >
> >> > +#define VFS_NS_CAP_EFFECTIVE0x1
> >> > +/*
> >> > + * 32-bit hdr_info contains
> >> > + * 16 leftmost: reserved
> >> > + * next 8: flags (only VFS_NS_CAP_EFFECTIVE so far)
> >> > + * last 8: version
> >> > + */
> >> > +struct vfs_ns_cap_data {
> >> > +   __le32 magic_etc;
> >> > +   struct {
> >> > +   __le32 permitted;/* Little endian */
> >> > +   __le32 inheritable;  /* Little endian */
> >> > +   } data[VFS_CAP_U32];
> >> > +};
> >>
> >> This is identical to vfs_cap_data. Is there a reason not to re-use the
> >> existing one?
> >
> > Hm.  I used to have them completely different.  ATM the only difference
> > is what goes into the magic_etc, and that not very (different).  So
> > yeah it probably should be re-used.
> >
> >> > +
> >> >  #ifndef __KERNEL__
> >> >
> >> >  /*
> >> > diff --git a/include/uapi/linux/xattr.h b/include/uapi/linux/xattr.h
> >> > index 1590c49..67c80ab 100644
> >> > --- a/include/uapi/linux/xattr.h
> >> > +++ b/include/uapi/linux/xattr.h
> >> > @@ -68,6 +68,9 @@
> >> >  #define XATTR_CAPS_SUFFIX "capability"
> >> >  #define XATTR_NAME_CAPS XATTR_SECURITY_PREFIX XATTR_CAPS_SUFFIX
> >> >
> >> > +#define XATTR_NS_CAPS_SUFFIX "nscapability"
> >> > +#define XATTR_NAME_NS_CAPS XATTR_SECURITY_PREFIX XATTR_NS_CAPS_SUFFIX
> >> > +
> >> >  #define XATTR_POSIX_ACL_ACCESS  "posix_acl_access"
> >> >  #define XATTR_NAME_POSIX_ACL_ACCESS XATTR_SYSTEM_PREFIX 
> >> > XATTR_POSIX_ACL_ACCESS
> >> >  #define XATTR_POSIX_ACL_DEFAULT  "posix_acl_default"
> >>
> >> Are these documented anywhere in Documentation/ or in man pages? This
> >> seems like it'd need a man-page update too.
> >
> > Yeah, if we decide we're ok with this strategy I'll update those.
> >
> >> > diff --git a/security/commoncap.c b/security/commoncap.c
> >> > index 48071ed..8f3f34a 100644
> >> > --- a/security/commoncap.c
> >> > +++ b/security/commoncap.c
> >> > @@ -313,6 +313,10 @@ int cap_inode_need_killpriv(struct dentry *dentry)
> >> > if (!inode->i_op->getxattr)
> >> >return 0;
> >> >
> >> > +   error = inode->i_op->getxattr(dentry, XATTR_NAME_NS_CAPS, NULL, 
> >> > 0);
> >> > +   if (error > 0)
> >> > +   return 1;
> >> > +
> >> > error 

[PATCH] IPMI: reserve memio regions separately

[minyard]

From: Corey Minyard 

Commit d61a3ead2680 ("[PATCH] IPMI: reserve I/O ports separately")
changed the way I/O ports were reserved and includes this comment in
log:

 Some BIOSes reserve disjoint I/O regions in their ACPI tables for the IPMI
 controller.  This causes problems when trying to register the entire I/O
 region.  Therefore we must register each I/O port separately.

There is a similar problem with memio regions on an arm64 platform
(AMD Seattle). Where I see:

 ipmi message handler version 39.2
 ipmi_si AMDI0300:00: probing via device tree
 ipmi_si AMDI0300:00: ipmi_si: probing via ACPI
 ipmi_si AMDI0300:00: [mem 0xe001] regsize 1 spacing 4 irq 23
 ipmi_si: Adding ACPI-specified kcs state machine
 IPMI System Interface driver.
 ipmi_si: Trying ACPI-specified kcs state machine at mem \
  address 0xe001, slave address 0x0, irq 23
 ipmi_si: Could not set up I/O space

The problem is that the ACPI core registers disjoint regions for the
platform device:

e001-e001 : AMDI0300:00
e0010004-e0010004 : AMDI0300:00

and the ipmi_si driver tries to register one region e001-e0010004.

Based on a patch from Mark Salter 

Signed-off-by: Corey Minyard 
---
 drivers/char/ipmi/ipmi_si_intf.c | 40 +++-
 1 file changed, 27 insertions(+), 13 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index 6ecf9af..a815044 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -1637,25 +1637,28 @@ static void mem_outq(const struct si_sm_io *io, 
unsigned int offset,
 }
 #endif
 
-static void mem_cleanup(struct smi_info *info)
+static void mem_region_cleanup(struct smi_info *info, int num)
 {
unsigned long addr = info->io.addr_data;
-   int   mapsize;
+   int idx;
+
+   for (idx = 0; idx < num; idx++)
+   release_mem_region(addr + idx * info->io.regspacing,
+  info->io.regsize);
+}
 
+static void mem_cleanup(struct smi_info *info)
+{
if (info->io.addr) {
iounmap(info->io.addr);
-
-   mapsize = ((info->io_size * info->io.regspacing)
-  - (info->io.regspacing - info->io.regsize));
-
-   release_mem_region(addr, mapsize);
+   mem_region_cleanup(info, info->io_size);
}
 }
 
 static int mem_setup(struct smi_info *info)
 {
unsigned long addr = info->io.addr_data;
-   int   mapsize;
+   int   mapsize, idx;
 
if (!addr)
return -ENODEV;
@@ -1692,6 +1695,21 @@ static int mem_setup(struct smi_info *info)
}
 
/*
+* Some BIOSes reserve disjoint memory regions in their ACPI
+* tables.  This causes problems when trying to request the
+* entire region.  Therefore we must request each register
+* separately.
+*/
+   for (idx = 0; idx < info->io_size; idx++) {
+   if (request_mem_region(addr + idx * info->io.regspacing,
+  info->io.regsize, DEVICE_NAME) == NULL) {
+   /* Undo allocations */
+   mem_region_cleanup(info, idx);
+   return -EIO;
+   }
+   }
+
+   /*
 * Calculate the total amount of memory to claim.  This is an
 * unusual looking calculation, but it avoids claiming any
 * more memory than it has to.  It will claim everything
@@ -1700,13 +1718,9 @@ static int mem_setup(struct smi_info *info)
 */
mapsize = ((info->io_size * info->io.regspacing)
   - (info->io.regspacing - info->io.regsize));
-
-   if (request_mem_region(addr, mapsize, DEVICE_NAME) == NULL)
-   return -EIO;
-
info->io.addr = ioremap(addr, mapsize);
if (info->io.addr == NULL) {
-   release_mem_region(addr, mapsize);
+   mem_region_cleanup(info, info->io_size);
return -EIO;
}
return 0;
-- 
2.7.4

[PATCH] IPMI: reserve memio regions separately

[minyard]

From: Corey Minyard 

Commit d61a3ead2680 ("[PATCH] IPMI: reserve I/O ports separately")
changed the way I/O ports were reserved and includes this comment in
log:

 Some BIOSes reserve disjoint I/O regions in their ACPI tables for the IPMI
 controller.  This causes problems when trying to register the entire I/O
 region.  Therefore we must register each I/O port separately.

There is a similar problem with memio regions on an arm64 platform
(AMD Seattle). Where I see:

 ipmi message handler version 39.2
 ipmi_si AMDI0300:00: probing via device tree
 ipmi_si AMDI0300:00: ipmi_si: probing via ACPI
 ipmi_si AMDI0300:00: [mem 0xe001] regsize 1 spacing 4 irq 23
 ipmi_si: Adding ACPI-specified kcs state machine
 IPMI System Interface driver.
 ipmi_si: Trying ACPI-specified kcs state machine at mem \
  address 0xe001, slave address 0x0, irq 23
 ipmi_si: Could not set up I/O space

The problem is that the ACPI core registers disjoint regions for the
platform device:

e001-e001 : AMDI0300:00
e0010004-e0010004 : AMDI0300:00

and the ipmi_si driver tries to register one region e001-e0010004.

Based on a patch from Mark Salter 

Signed-off-by: Corey Minyard 
---
 drivers/char/ipmi/ipmi_si_intf.c | 40 +++-
 1 file changed, 27 insertions(+), 13 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index 6ecf9af..a815044 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -1637,25 +1637,28 @@ static void mem_outq(const struct si_sm_io *io, 
unsigned int offset,
 }
 #endif
 
-static void mem_cleanup(struct smi_info *info)
+static void mem_region_cleanup(struct smi_info *info, int num)
 {
unsigned long addr = info->io.addr_data;
-   int   mapsize;
+   int idx;
+
+   for (idx = 0; idx < num; idx++)
+   release_mem_region(addr + idx * info->io.regspacing,
+  info->io.regsize);
+}
 
+static void mem_cleanup(struct smi_info *info)
+{
if (info->io.addr) {
iounmap(info->io.addr);
-
-   mapsize = ((info->io_size * info->io.regspacing)
-  - (info->io.regspacing - info->io.regsize));
-
-   release_mem_region(addr, mapsize);
+   mem_region_cleanup(info, info->io_size);
}
 }
 
 static int mem_setup(struct smi_info *info)
 {
unsigned long addr = info->io.addr_data;
-   int   mapsize;
+   int   mapsize, idx;
 
if (!addr)
return -ENODEV;
@@ -1692,6 +1695,21 @@ static int mem_setup(struct smi_info *info)
}
 
/*
+* Some BIOSes reserve disjoint memory regions in their ACPI
+* tables.  This causes problems when trying to request the
+* entire region.  Therefore we must request each register
+* separately.
+*/
+   for (idx = 0; idx < info->io_size; idx++) {
+   if (request_mem_region(addr + idx * info->io.regspacing,
+  info->io.regsize, DEVICE_NAME) == NULL) {
+   /* Undo allocations */
+   mem_region_cleanup(info, idx);
+   return -EIO;
+   }
+   }
+
+   /*
 * Calculate the total amount of memory to claim.  This is an
 * unusual looking calculation, but it avoids claiming any
 * more memory than it has to.  It will claim everything
@@ -1700,13 +1718,9 @@ static int mem_setup(struct smi_info *info)
 */
mapsize = ((info->io_size * info->io.regspacing)
   - (info->io.regspacing - info->io.regsize));
-
-   if (request_mem_region(addr, mapsize, DEVICE_NAME) == NULL)
-   return -EIO;
-
info->io.addr = ioremap(addr, mapsize);
if (info->io.addr == NULL) {
-   release_mem_region(addr, mapsize);
+   mem_region_cleanup(info, info->io_size);
return -EIO;
}
return 0;
-- 
2.7.4

Re: random(4) changes

[Herbert Xu]

On Tue, Apr 26, 2016 at 01:47:09PM -0700, Andi Kleen wrote:
>
> I posted patches to fix this. At some point it definitely has to be.

Can you point me to the patch submission?

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: random(4) changes

[Herbert Xu]

On Tue, Apr 26, 2016 at 01:47:09PM -0700, Andi Kleen wrote:
>
> I posted patches to fix this. At some point it definitely has to be.

Can you point me to the patch submission?

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[PATCH] mmc: sdhci-of-arasan: refactor set_clock callback

[Shawn Lin]

commit 61b914eb81f8 ("mmc: sdhci-of-arasan: add phy support for
sdhci-of-arasan") introduce phy support for arasan. According to
the vendor's databook, we should make sure the phy is in poweroff
status before we configure the clk stuff. Otherwise it may cause
some IO sample timing issues from the test. And we don't need this
extra operation while running in low perfermance mode since phy
doesn't trigger sampling block.

Signed-off-by: Shawn Lin 
---

 drivers/mmc/host/sdhci-of-arasan.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-of-arasan.c 
b/drivers/mmc/host/sdhci-of-arasan.c
index 2e482b1..20b859e 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -55,8 +55,26 @@ static unsigned int sdhci_arasan_get_timeout_clock(struct 
sdhci_host *host)
return freq;
 }
 
+static void sdhci_arasan_set_clock(struct sdhci_host *host, unsigned int clock)
+{
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_arasan_data *sdhci_arasan = sdhci_pltfm_priv(pltfm_host);
+   bool ctrl_phy = false;
+
+   if (clock > MMC_HIGH_52_MAX_DTR && (!IS_ERR(sdhci_arasan->phy)))
+   ctrl_phy = true;
+
+   if (ctrl_phy)
+   phy_power_off(sdhci_arasan->phy);
+
+   sdhci_set_clock(host, clock);
+
+   if (ctrl_phy)
+   phy_power_on(sdhci_arasan->phy);
+}
+
 static struct sdhci_ops sdhci_arasan_ops = {
-   .set_clock = sdhci_set_clock,
+   .set_clock = sdhci_arasan_set_clock,
.get_max_clock = sdhci_pltfm_clk_get_max_clock,
.get_timeout_clock = sdhci_arasan_get_timeout_clock,
.set_bus_width = sdhci_set_bus_width,
-- 
2.3.7

[PATCH] mmc: sdhci-of-arasan: refactor set_clock callback

[Shawn Lin]

commit 61b914eb81f8 ("mmc: sdhci-of-arasan: add phy support for
sdhci-of-arasan") introduce phy support for arasan. According to
the vendor's databook, we should make sure the phy is in poweroff
status before we configure the clk stuff. Otherwise it may cause
some IO sample timing issues from the test. And we don't need this
extra operation while running in low perfermance mode since phy
doesn't trigger sampling block.

Signed-off-by: Shawn Lin 
---

 drivers/mmc/host/sdhci-of-arasan.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-of-arasan.c 
b/drivers/mmc/host/sdhci-of-arasan.c
index 2e482b1..20b859e 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -55,8 +55,26 @@ static unsigned int sdhci_arasan_get_timeout_clock(struct 
sdhci_host *host)
return freq;
 }
 
+static void sdhci_arasan_set_clock(struct sdhci_host *host, unsigned int clock)
+{
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_arasan_data *sdhci_arasan = sdhci_pltfm_priv(pltfm_host);
+   bool ctrl_phy = false;
+
+   if (clock > MMC_HIGH_52_MAX_DTR && (!IS_ERR(sdhci_arasan->phy)))
+   ctrl_phy = true;
+
+   if (ctrl_phy)
+   phy_power_off(sdhci_arasan->phy);
+
+   sdhci_set_clock(host, clock);
+
+   if (ctrl_phy)
+   phy_power_on(sdhci_arasan->phy);
+}
+
 static struct sdhci_ops sdhci_arasan_ops = {
-   .set_clock = sdhci_set_clock,
+   .set_clock = sdhci_arasan_set_clock,
.get_max_clock = sdhci_pltfm_clk_get_max_clock,
.get_timeout_clock = sdhci_arasan_get_timeout_clock,
.set_bus_width = sdhci_set_bus_width,
-- 
2.3.7

RE: [PATCH] scripts/spelling.txt: add "fimware" misspelling

[Zhao Lei]

Hi, Kees Cook

* From: Kees Cook [mailto:keesc...@chromium.org]
> Sent: Wednesday, April 27, 2016 7:48 AM
> To: Andrew Morton 
> Cc: Randy Dunlap ; Andy Whitcroft
> ; Joe Perches ; Zhao Lei
> ; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: [PATCH] scripts/spelling.txt: add "fimware" misspelling
> 
> A few instances of "fimware" instead of "firmware" were found. Fix these
> and add it to the spelling.txt file.
> 
Better to add this change:
  # grep fimware * -R
  Documentation/firmware_class/README:- kernel searchs the fimware image 
with name $FIRMWARE directly

Thanks
Zhaolei

> Reported-by: Randy Dunlap 
> Signed-off-by: Kees Cook 
> ---
> Looks like spelling.txt changes have been going in through -mm?
> ---
>  drivers/media/usb/dvb-usb/dib0700_core.c  | 2 +-
>  drivers/scsi/bfa/bfi.h| 2 +-
>  drivers/staging/comedi/drivers/daqboard2000.c | 2 +-
>  scripts/spelling.txt  | 1 +
>  4 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/usb/dvb-usb/dib0700_core.c
> b/drivers/media/usb/dvb-usb/dib0700_core.c
> index c16f999b9d7c..bf890c3d9cda 100644
> --- a/drivers/media/usb/dvb-usb/dib0700_core.c
> +++ b/drivers/media/usb/dvb-usb/dib0700_core.c
> @@ -517,7 +517,7 @@ int dib0700_download_firmware(struct usb_device
> *udev, const struct firmware *fw
>   if (nb_packet_buffer_size < 1)
>   nb_packet_buffer_size = 1;
> 
> - /* get the fimware version */
> + /* get the firmware version */
>   usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
> REQUEST_GET_VERSION,
> USB_TYPE_VENDOR | USB_DIR_IN, 0, 0,
> diff --git a/drivers/scsi/bfa/bfi.h b/drivers/scsi/bfa/bfi.h
> index 97600dcec649..5f698d038b21 100644
> --- a/drivers/scsi/bfa/bfi.h
> +++ b/drivers/scsi/bfa/bfi.h
> @@ -356,7 +356,7 @@ struct bfi_ioc_image_hdr_s {
>   u8  port0_mode; /* device mode for port 0   */
>   u8  port1_mode; /* device mode for port 1   */
>   u32 exec;   /* exec vector  */
> - u32 bootenv;/* fimware boot env */
> + u32 bootenv;/* firmware boot env*/
>   u32 rsvd_b[2];
>   struct bfi_ioc_fwver_s  fwver;
>   u32 md5sum[BFI_IOC_MD5SUM_SZ];
> diff --git a/drivers/staging/comedi/drivers/daqboard2000.c
> b/drivers/staging/comedi/drivers/daqboard2000.c
> index 57ab6680e3ae..a536a15c1d30 100644
> --- a/drivers/staging/comedi/drivers/daqboard2000.c
> +++ b/drivers/staging/comedi/drivers/daqboard2000.c
> @@ -26,7 +26,7 @@
>   * Much of the functionality of this driver was determined from reading
>   * the source code for the Windows driver.
>   *
> - * The FPGA on the board requires fimware, which is available from
> + * The FPGA on the board requires firmware, which is available from
>   * http://www.comedi.org in the comedi_nonfree_firmware tarball.
>   *
>   * Configuration options: not applicable, uses PCI auto config
> diff --git a/scripts/spelling.txt b/scripts/spelling.txt
> index 946caf3bd694..fa79c6d2a5b8 100644
> --- a/scripts/spelling.txt
> +++ b/scripts/spelling.txt
> @@ -428,6 +428,7 @@ feautures||features
>  fetaure||feature
>  fetaures||features
>  fileystem||filesystem
> +fimware||firmware
>  finanize||finalize
>  findn||find
>  finilizes||finalizes
> --
> 2.6.3
> 
> 
> --
> Kees Cook
> Chrome OS & Brillo Security

RE: [PATCH] scripts/spelling.txt: add "fimware" misspelling

[Zhao Lei]

Hi, Kees Cook

* From: Kees Cook [mailto:keesc...@chromium.org]
> Sent: Wednesday, April 27, 2016 7:48 AM
> To: Andrew Morton 
> Cc: Randy Dunlap ; Andy Whitcroft
> ; Joe Perches ; Zhao Lei
> ; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: [PATCH] scripts/spelling.txt: add "fimware" misspelling
> 
> A few instances of "fimware" instead of "firmware" were found. Fix these
> and add it to the spelling.txt file.
> 
Better to add this change:
  # grep fimware * -R
  Documentation/firmware_class/README:- kernel searchs the fimware image 
with name $FIRMWARE directly

Thanks
Zhaolei

> Reported-by: Randy Dunlap 
> Signed-off-by: Kees Cook 
> ---
> Looks like spelling.txt changes have been going in through -mm?
> ---
>  drivers/media/usb/dvb-usb/dib0700_core.c  | 2 +-
>  drivers/scsi/bfa/bfi.h| 2 +-
>  drivers/staging/comedi/drivers/daqboard2000.c | 2 +-
>  scripts/spelling.txt  | 1 +
>  4 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/usb/dvb-usb/dib0700_core.c
> b/drivers/media/usb/dvb-usb/dib0700_core.c
> index c16f999b9d7c..bf890c3d9cda 100644
> --- a/drivers/media/usb/dvb-usb/dib0700_core.c
> +++ b/drivers/media/usb/dvb-usb/dib0700_core.c
> @@ -517,7 +517,7 @@ int dib0700_download_firmware(struct usb_device
> *udev, const struct firmware *fw
>   if (nb_packet_buffer_size < 1)
>   nb_packet_buffer_size = 1;
> 
> - /* get the fimware version */
> + /* get the firmware version */
>   usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
> REQUEST_GET_VERSION,
> USB_TYPE_VENDOR | USB_DIR_IN, 0, 0,
> diff --git a/drivers/scsi/bfa/bfi.h b/drivers/scsi/bfa/bfi.h
> index 97600dcec649..5f698d038b21 100644
> --- a/drivers/scsi/bfa/bfi.h
> +++ b/drivers/scsi/bfa/bfi.h
> @@ -356,7 +356,7 @@ struct bfi_ioc_image_hdr_s {
>   u8  port0_mode; /* device mode for port 0   */
>   u8  port1_mode; /* device mode for port 1   */
>   u32 exec;   /* exec vector  */
> - u32 bootenv;/* fimware boot env */
> + u32 bootenv;/* firmware boot env*/
>   u32 rsvd_b[2];
>   struct bfi_ioc_fwver_s  fwver;
>   u32 md5sum[BFI_IOC_MD5SUM_SZ];
> diff --git a/drivers/staging/comedi/drivers/daqboard2000.c
> b/drivers/staging/comedi/drivers/daqboard2000.c
> index 57ab6680e3ae..a536a15c1d30 100644
> --- a/drivers/staging/comedi/drivers/daqboard2000.c
> +++ b/drivers/staging/comedi/drivers/daqboard2000.c
> @@ -26,7 +26,7 @@
>   * Much of the functionality of this driver was determined from reading
>   * the source code for the Windows driver.
>   *
> - * The FPGA on the board requires fimware, which is available from
> + * The FPGA on the board requires firmware, which is available from
>   * http://www.comedi.org in the comedi_nonfree_firmware tarball.
>   *
>   * Configuration options: not applicable, uses PCI auto config
> diff --git a/scripts/spelling.txt b/scripts/spelling.txt
> index 946caf3bd694..fa79c6d2a5b8 100644
> --- a/scripts/spelling.txt
> +++ b/scripts/spelling.txt
> @@ -428,6 +428,7 @@ feautures||features
>  fetaure||feature
>  fetaures||features
>  fileystem||filesystem
> +fimware||firmware
>  finanize||finalize
>  findn||find
>  finilizes||finalizes
> --
> 2.6.3
> 
> 
> --
> Kees Cook
> Chrome OS & Brillo Security

Re: [PATCH v2 3/3] block: avoid to call .bi_end_io() recursively

[Ming Lei]

On Wed, Apr 27, 2016 at 12:02 PM, NeilBrown  wrote:
> On Wed, Apr 27 2016, Ming Lei wrote:
>
>> There were reports about heavy stack use by recursive calling
>> .bi_end_io()([1][2][3]). For example, more than 16K stack is
>> consumed in a single bio complete path[3], and in [2] stack
>> overflow can be triggered if 20 nested dm-crypt is used.
>>
>> Also patches[1] [2] [3] were posted for addressing the issue,
>> but never be merged. And the idea in these patches is basically
>> similar, all serializes the recursive calling of .bi_end_io() by
>> percpu list.
>>
>> This patch still takes the same idea, but uses bio_list to
>> implement it, which turns out more simple and the code becomes
>> more readable meantime.
>>
>> One corner case which wasn't covered before is that
>> bi_endio() may be scheduled to run in process context(such
>> as btrfs), and this patch just bypasses the optimizing for
>> that case because one new context should have enough stack space,
>> and this approach isn't capable of optimizing it too because
>> there isn't easy way to get a per-task linked list head.
>>
>> xfstests(-g auto) is run with this patch and no regression is
>> found on ext4, xfs and btrfs.
>>
>> [1] http://marc.info/?t=12142850204=1=2
>> [2] http://marc.info/?l=dm-devel=139595190620008=2
>> [3] http://marc.info/?t=14597464411=1=2
>>
>> Cc: Shaun Tancheff 
>> Cc: Christoph Hellwig 
>> Cc: Mikulas Patocka 
>> Cc: Alan Cox 
>> Cc: Neil Brown 
>> Cc: Liu Bo 
>> Signed-off-by: Ming Lei 
>> ---
>>  block/bio.c | 57 +++--
>>  1 file changed, 55 insertions(+), 2 deletions(-)
>>
>> diff --git a/block/bio.c b/block/bio.c
>> index 807d25e..6b4ca7b 100644
>> --- a/block/bio.c
>> +++ b/block/bio.c
>> @@ -68,6 +68,8 @@ static DEFINE_MUTEX(bio_slab_lock);
>>  static struct bio_slab *bio_slabs;
>>  static unsigned int bio_slab_nr, bio_slab_max;
>>
>> +static DEFINE_PER_CPU(struct bio_list *, bio_end_list) = { NULL };
>> +
>>  static struct kmem_cache *bio_find_or_create_slab(unsigned int extra_size)
>>  {
>>   unsigned int sz = sizeof(struct bio) + extra_size;
>> @@ -1737,6 +1739,58 @@ static inline bool bio_remaining_done(struct bio *bio)
>>   return false;
>>  }
>>
>> +static void __bio_endio(struct bio *bio)
>> +{
>> + if (bio->bi_end_io)
>> + bio->bi_end_io(bio);
>> +}
>> +
>> +/* disable local irq when manipulating the percpu bio_list */
>> +static void unwind_bio_endio(struct bio *bio)
>> +{
>> + struct bio_list *bl;
>> + unsigned long flags;
>> +
>> + /*
>> +  * We can't optimize if bi_endio() is scheduled to run from
>> +  * process context because there isn't easy way to get a
>> +  * per-task bio list head or allocate a per-task variable.
>> +  */
>> + if (!in_interrupt()) {
>> + /*
>> +  * It has to be a top calling when it is run from
>> +  * process context.
>> +  */
>> + WARN_ON(this_cpu_read(bio_end_list));
>> + __bio_endio(bio);
>> + return;
>> + }
>> +
>> + local_irq_save(flags);
>> + bl = __this_cpu_read(bio_end_list);
>> + if (!bl) {
>> + struct bio_list bl_in_stack;
>> +
>> + bl = _in_stack;
>> + bio_list_init(bl);
>> + __this_cpu_write(bio_end_list, bl);
>
> The patch seems to make sense, but this bit bothers me.
> You are expecting bl_in_stack to still be usable after this block of
> code completes.  While it probably is, I don't think it is a good idea
> to depend on it.
> If you move the "struct bio_list bl_in_stack" to the top of the function
> I would be a lot happier.
>
> Or you could change the code to:
>
>if (bl) {
>bio_list_add(bl, bio);
>} else {
>struct bio_list bl_in_stack;
>... use bl_in_stack,
>while loop
>set bio_end_list to NULL
>}
>
> and the code flow would all be must clearer.

Yeah, definitely, thanks for the point.

Thanks,

>
> Thanks,
> NeilBrown
>
>> + } else {
>> + bio_list_add(bl, bio);
>> + goto out;
>> + }
>> +
>> + while (bio) {
>> + local_irq_restore(flags);
>> + __bio_endio(bio);
>> + local_irq_save(flags);
>> +> +  bio = bio_list_pop(bl);
>> + }
>> + __this_cpu_write(bio_end_list, NULL);
>> + out:
>> + local_irq_restore(flags);
>> +}
>> +
>>  /**
>>   * bio_endio - end I/O on a bio
>>   * @bio: bio
>> @@ -1765,8 +1819,7 @@ again:
>>   goto again;
>>   }
>>
>> - if (bio->bi_end_io)
>> - bio->bi_end_io(bio);
>> + unwind_bio_endio(bio);
>>  }
>>  EXPORT_SYMBOL(bio_endio);
>>
>> --
>> 1.9.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> 

Re: [PATCH v2 3/3] block: avoid to call .bi_end_io() recursively

[Ming Lei]

On Wed, Apr 27, 2016 at 12:02 PM, NeilBrown  wrote:
> On Wed, Apr 27 2016, Ming Lei wrote:
>
>> There were reports about heavy stack use by recursive calling
>> .bi_end_io()([1][2][3]). For example, more than 16K stack is
>> consumed in a single bio complete path[3], and in [2] stack
>> overflow can be triggered if 20 nested dm-crypt is used.
>>
>> Also patches[1] [2] [3] were posted for addressing the issue,
>> but never be merged. And the idea in these patches is basically
>> similar, all serializes the recursive calling of .bi_end_io() by
>> percpu list.
>>
>> This patch still takes the same idea, but uses bio_list to
>> implement it, which turns out more simple and the code becomes
>> more readable meantime.
>>
>> One corner case which wasn't covered before is that
>> bi_endio() may be scheduled to run in process context(such
>> as btrfs), and this patch just bypasses the optimizing for
>> that case because one new context should have enough stack space,
>> and this approach isn't capable of optimizing it too because
>> there isn't easy way to get a per-task linked list head.
>>
>> xfstests(-g auto) is run with this patch and no regression is
>> found on ext4, xfs and btrfs.
>>
>> [1] http://marc.info/?t=12142850204=1=2
>> [2] http://marc.info/?l=dm-devel=139595190620008=2
>> [3] http://marc.info/?t=14597464411=1=2
>>
>> Cc: Shaun Tancheff 
>> Cc: Christoph Hellwig 
>> Cc: Mikulas Patocka 
>> Cc: Alan Cox 
>> Cc: Neil Brown 
>> Cc: Liu Bo 
>> Signed-off-by: Ming Lei 
>> ---
>>  block/bio.c | 57 +++--
>>  1 file changed, 55 insertions(+), 2 deletions(-)
>>
>> diff --git a/block/bio.c b/block/bio.c
>> index 807d25e..6b4ca7b 100644
>> --- a/block/bio.c
>> +++ b/block/bio.c
>> @@ -68,6 +68,8 @@ static DEFINE_MUTEX(bio_slab_lock);
>>  static struct bio_slab *bio_slabs;
>>  static unsigned int bio_slab_nr, bio_slab_max;
>>
>> +static DEFINE_PER_CPU(struct bio_list *, bio_end_list) = { NULL };
>> +
>>  static struct kmem_cache *bio_find_or_create_slab(unsigned int extra_size)
>>  {
>>   unsigned int sz = sizeof(struct bio) + extra_size;
>> @@ -1737,6 +1739,58 @@ static inline bool bio_remaining_done(struct bio *bio)
>>   return false;
>>  }
>>
>> +static void __bio_endio(struct bio *bio)
>> +{
>> + if (bio->bi_end_io)
>> + bio->bi_end_io(bio);
>> +}
>> +
>> +/* disable local irq when manipulating the percpu bio_list */
>> +static void unwind_bio_endio(struct bio *bio)
>> +{
>> + struct bio_list *bl;
>> + unsigned long flags;
>> +
>> + /*
>> +  * We can't optimize if bi_endio() is scheduled to run from
>> +  * process context because there isn't easy way to get a
>> +  * per-task bio list head or allocate a per-task variable.
>> +  */
>> + if (!in_interrupt()) {
>> + /*
>> +  * It has to be a top calling when it is run from
>> +  * process context.
>> +  */
>> + WARN_ON(this_cpu_read(bio_end_list));
>> + __bio_endio(bio);
>> + return;
>> + }
>> +
>> + local_irq_save(flags);
>> + bl = __this_cpu_read(bio_end_list);
>> + if (!bl) {
>> + struct bio_list bl_in_stack;
>> +
>> + bl = _in_stack;
>> + bio_list_init(bl);
>> + __this_cpu_write(bio_end_list, bl);
>
> The patch seems to make sense, but this bit bothers me.
> You are expecting bl_in_stack to still be usable after this block of
> code completes.  While it probably is, I don't think it is a good idea
> to depend on it.
> If you move the "struct bio_list bl_in_stack" to the top of the function
> I would be a lot happier.
>
> Or you could change the code to:
>
>if (bl) {
>bio_list_add(bl, bio);
>} else {
>struct bio_list bl_in_stack;
>... use bl_in_stack,
>while loop
>set bio_end_list to NULL
>}
>
> and the code flow would all be must clearer.

Yeah, definitely, thanks for the point.

Thanks,

>
> Thanks,
> NeilBrown
>
>> + } else {
>> + bio_list_add(bl, bio);
>> + goto out;
>> + }
>> +
>> + while (bio) {
>> + local_irq_restore(flags);
>> + __bio_endio(bio);
>> + local_irq_save(flags);
>> +> +  bio = bio_list_pop(bl);
>> + }
>> + __this_cpu_write(bio_end_list, NULL);
>> + out:
>> + local_irq_restore(flags);
>> +}
>> +
>>  /**
>>   * bio_endio - end I/O on a bio
>>   * @bio: bio
>> @@ -1765,8 +1819,7 @@ again:
>>   goto again;
>>   }
>>
>> - if (bio->bi_end_io)
>> - bio->bi_end_io(bio);
>> + unwind_bio_endio(bio);
>>  }
>>  EXPORT_SYMBOL(bio_endio);
>>
>> --
>> 1.9.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 12/14] arm64, acpi, numa: NUMA support based on SRAT and SLIT

[Hanjun Guo]

Hi Dennis, David,

Sorry for the late reply, please see my comments below.

On 2016/4/27 9:14, David Daney wrote:

On 04/21/2016 03:06 AM, Dennis Chen wrote:

On 20 April 2016 at 09:40, David Daney  wrote:

[...]

+/* Callback for Proximity Domain -> ACPI processor UID mapping */
+void __init acpi_numa_gicc_affinity_init(struct
acpi_srat_gicc_affinity *pa)
+{
+   int pxm, node;
+   u64 mpidr;
+
+   if (srat_disabled())
+   return;
+
+   if (pa->header.length < sizeof(struct
acpi_srat_gicc_affinity)) {
+   pr_err("SRAT: Invalid SRAT header length: %d\n",
+   pa->header.length);
+   bad_srat();
+   return;
+   }
+
+   if (!(pa->flags & ACPI_SRAT_GICC_ENABLED))
+   return;
+
+   if (cpus_in_srat >= NR_CPUS) {
+   pr_warn_once("SRAT: cpu_to_node_map[%d] is too small,
may not be able to use all cpus\n",
+NR_CPUS);
+   return;
+   }
+
+   pxm = pa->proximity_domain;
+   node = acpi_map_pxm_to_node(pxm);
+
+   if (node == NUMA_NO_NODE || node >= MAX_NUMNODES) {
+   pr_err("SRAT: Too many proximity domains %d\n", pxm);
+   bad_srat();
+   return;
+   }
+
+   if (get_mpidr_in_madt(pa->acpi_processor_uid, )) {
+   pr_err("SRAT: PXM %d with ACPI ID %d has no valid
MPIDR in MADT\n",
+   pxm, pa->acpi_processor_uid);
+   bad_srat();
+   return;
+   }
+
+   early_node_cpu_hwid[cpus_in_srat].node_id = node;
+   early_node_cpu_hwid[cpus_in_srat].cpu_hwid =  mpidr;
+   node_set(node, numa_nodes_parsed);
+   cpus_in_srat++;
+   pr_info("SRAT: PXM %d -> MPIDR 0x%Lx -> Node %d cpu %d\n",
+   pxm, mpidr, node, cpus_in_srat);
+}


What does the *cpu* means in above pr_info function? If it's the
logical processor ID or ACPI processor UID, then I suggest to use
pa->acpi_processor_uid instead of cpus_in_srat, I understand the


I think print cpus_in_srat is pointless here, as the logic cpu number
is allocated by OS when initializing SMP by scanning MADT table. As
Dennis said, it's just a count number, not a number mapping to MPIDR.

ACPI processor UID is the key value to connect MADT, SRAT, DSDT.

For MADT, it will have MPIDR and ACPI processor UID, and OS will
create mappings to MPIDR and cpu logical number,
ACPI processor UID <--> MPIDR <--> CPU logical number

In SRAT, there is ACPI processor UID represented, mappings will be
ACPI processor UID <--> PXM <--> NUMA node logical number

So we can use ACPI processor UID to get the MPIDR by scanning the
MADT, then we can map NUMA node logical number to cpu logical
number later.


cpus_in_srat is just a count number of the entries of GICC Affinity
Struct instance in SRAT, correct me if I am wrong. So at least it sees
to me, the above pr_info will output message looks like:
SRAT: PXM 0 -> MPIDR 0x100 -> Node 0 cpu 1
SRAT: PXM 0 -> MPIDR 0x101 -> Node 0 cpu 2
SRAT: PXM 0 -> MPIDR 0x102 -> Node 0 cpu 3



Yes, that is correct, and for my system seems to be what we want as the
names in /sys/devices/system/cpu/ and /proc/cpu_info agree with the
sequential numbering (0..95) with 48 CPUs on each node.


That's because you place CPUs in the same order both in MADT and SRAT :)
if not, that will be not match.



If I make the change you suggest, I get :
.
.
.
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x0 -> Node 0 cpu 0
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x1 -> Node 0 cpu 1
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x2 -> Node 0 cpu 2
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x3 -> Node 0 cpu 3
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x4 -> Node 0 cpu 4
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x5 -> Node 0 cpu 5
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x6 -> Node 0 cpu 6
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x7 -> Node 0 cpu 7
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x8 -> Node 0 cpu 8
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x9 -> Node 0 cpu 9
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0xa -> Node 0 cpu 10
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0xb -> Node 0 cpu 11
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0xc -> Node 0 cpu 12
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0xd -> Node 0 cpu 13
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0xe -> Node 0 cpu 14
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0xf -> Node 0 cpu 15
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x100 -> Node 0 cpu 256
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x101 -> Node 0 cpu 257
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x102 -> Node 0 cpu 258
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x103 -> Node 0 cpu 259
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x104 -> Node 0 cpu 260
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x105 -> Node 0 

Re: [PATCH v5 12/14] arm64, acpi, numa: NUMA support based on SRAT and SLIT

[Hanjun Guo]

Hi Dennis, David,

Sorry for the late reply, please see my comments below.

On 2016/4/27 9:14, David Daney wrote:

On 04/21/2016 03:06 AM, Dennis Chen wrote:

On 20 April 2016 at 09:40, David Daney  wrote:

[...]

+/* Callback for Proximity Domain -> ACPI processor UID mapping */
+void __init acpi_numa_gicc_affinity_init(struct
acpi_srat_gicc_affinity *pa)
+{
+   int pxm, node;
+   u64 mpidr;
+
+   if (srat_disabled())
+   return;
+
+   if (pa->header.length < sizeof(struct
acpi_srat_gicc_affinity)) {
+   pr_err("SRAT: Invalid SRAT header length: %d\n",
+   pa->header.length);
+   bad_srat();
+   return;
+   }
+
+   if (!(pa->flags & ACPI_SRAT_GICC_ENABLED))
+   return;
+
+   if (cpus_in_srat >= NR_CPUS) {
+   pr_warn_once("SRAT: cpu_to_node_map[%d] is too small,
may not be able to use all cpus\n",
+NR_CPUS);
+   return;
+   }
+
+   pxm = pa->proximity_domain;
+   node = acpi_map_pxm_to_node(pxm);
+
+   if (node == NUMA_NO_NODE || node >= MAX_NUMNODES) {
+   pr_err("SRAT: Too many proximity domains %d\n", pxm);
+   bad_srat();
+   return;
+   }
+
+   if (get_mpidr_in_madt(pa->acpi_processor_uid, )) {
+   pr_err("SRAT: PXM %d with ACPI ID %d has no valid
MPIDR in MADT\n",
+   pxm, pa->acpi_processor_uid);
+   bad_srat();
+   return;
+   }
+
+   early_node_cpu_hwid[cpus_in_srat].node_id = node;
+   early_node_cpu_hwid[cpus_in_srat].cpu_hwid =  mpidr;
+   node_set(node, numa_nodes_parsed);
+   cpus_in_srat++;
+   pr_info("SRAT: PXM %d -> MPIDR 0x%Lx -> Node %d cpu %d\n",
+   pxm, mpidr, node, cpus_in_srat);
+}


What does the *cpu* means in above pr_info function? If it's the
logical processor ID or ACPI processor UID, then I suggest to use
pa->acpi_processor_uid instead of cpus_in_srat, I understand the


I think print cpus_in_srat is pointless here, as the logic cpu number
is allocated by OS when initializing SMP by scanning MADT table. As
Dennis said, it's just a count number, not a number mapping to MPIDR.

ACPI processor UID is the key value to connect MADT, SRAT, DSDT.

For MADT, it will have MPIDR and ACPI processor UID, and OS will
create mappings to MPIDR and cpu logical number,
ACPI processor UID <--> MPIDR <--> CPU logical number

In SRAT, there is ACPI processor UID represented, mappings will be
ACPI processor UID <--> PXM <--> NUMA node logical number

So we can use ACPI processor UID to get the MPIDR by scanning the
MADT, then we can map NUMA node logical number to cpu logical
number later.


cpus_in_srat is just a count number of the entries of GICC Affinity
Struct instance in SRAT, correct me if I am wrong. So at least it sees
to me, the above pr_info will output message looks like:
SRAT: PXM 0 -> MPIDR 0x100 -> Node 0 cpu 1
SRAT: PXM 0 -> MPIDR 0x101 -> Node 0 cpu 2
SRAT: PXM 0 -> MPIDR 0x102 -> Node 0 cpu 3



Yes, that is correct, and for my system seems to be what we want as the
names in /sys/devices/system/cpu/ and /proc/cpu_info agree with the
sequential numbering (0..95) with 48 CPUs on each node.


That's because you place CPUs in the same order both in MADT and SRAT :)
if not, that will be not match.



If I make the change you suggest, I get :
.
.
.
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x0 -> Node 0 cpu 0
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x1 -> Node 0 cpu 1
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x2 -> Node 0 cpu 2
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x3 -> Node 0 cpu 3
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x4 -> Node 0 cpu 4
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x5 -> Node 0 cpu 5
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x6 -> Node 0 cpu 6
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x7 -> Node 0 cpu 7
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x8 -> Node 0 cpu 8
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x9 -> Node 0 cpu 9
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0xa -> Node 0 cpu 10
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0xb -> Node 0 cpu 11
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0xc -> Node 0 cpu 12
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0xd -> Node 0 cpu 13
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0xe -> Node 0 cpu 14
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0xf -> Node 0 cpu 15
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x100 -> Node 0 cpu 256
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x101 -> Node 0 cpu 257
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x102 -> Node 0 cpu 258
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x103 -> Node 0 cpu 259
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x104 -> Node 0 cpu 260
[0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x105 -> Node 0 cpu 261
[0.00] 

Re: [PATCH v2 3/3] block: avoid to call .bi_end_io() recursively

[NeilBrown]

On Wed, Apr 27 2016, Ming Lei wrote:

> There were reports about heavy stack use by recursive calling
> .bi_end_io()([1][2][3]). For example, more than 16K stack is
> consumed in a single bio complete path[3], and in [2] stack
> overflow can be triggered if 20 nested dm-crypt is used.
>
> Also patches[1] [2] [3] were posted for addressing the issue,
> but never be merged. And the idea in these patches is basically
> similar, all serializes the recursive calling of .bi_end_io() by
> percpu list.
>
> This patch still takes the same idea, but uses bio_list to
> implement it, which turns out more simple and the code becomes
> more readable meantime.
>
> One corner case which wasn't covered before is that
> bi_endio() may be scheduled to run in process context(such
> as btrfs), and this patch just bypasses the optimizing for
> that case because one new context should have enough stack space,
> and this approach isn't capable of optimizing it too because
> there isn't easy way to get a per-task linked list head.
>
> xfstests(-g auto) is run with this patch and no regression is
> found on ext4, xfs and btrfs.
>
> [1] http://marc.info/?t=12142850204=1=2
> [2] http://marc.info/?l=dm-devel=139595190620008=2
> [3] http://marc.info/?t=14597464411=1=2
>
> Cc: Shaun Tancheff 
> Cc: Christoph Hellwig 
> Cc: Mikulas Patocka 
> Cc: Alan Cox 
> Cc: Neil Brown 
> Cc: Liu Bo 
> Signed-off-by: Ming Lei 
> ---
>  block/bio.c | 57 +++--
>  1 file changed, 55 insertions(+), 2 deletions(-)
>
> diff --git a/block/bio.c b/block/bio.c
> index 807d25e..6b4ca7b 100644
> --- a/block/bio.c
> +++ b/block/bio.c
> @@ -68,6 +68,8 @@ static DEFINE_MUTEX(bio_slab_lock);
>  static struct bio_slab *bio_slabs;
>  static unsigned int bio_slab_nr, bio_slab_max;
>  
> +static DEFINE_PER_CPU(struct bio_list *, bio_end_list) = { NULL };
> +
>  static struct kmem_cache *bio_find_or_create_slab(unsigned int extra_size)
>  {
>   unsigned int sz = sizeof(struct bio) + extra_size;
> @@ -1737,6 +1739,58 @@ static inline bool bio_remaining_done(struct bio *bio)
>   return false;
>  }
>  
> +static void __bio_endio(struct bio *bio)
> +{
> + if (bio->bi_end_io)
> + bio->bi_end_io(bio);
> +}
> +
> +/* disable local irq when manipulating the percpu bio_list */
> +static void unwind_bio_endio(struct bio *bio)
> +{
> + struct bio_list *bl;
> + unsigned long flags;
> +
> + /*
> +  * We can't optimize if bi_endio() is scheduled to run from
> +  * process context because there isn't easy way to get a
> +  * per-task bio list head or allocate a per-task variable.
> +  */
> + if (!in_interrupt()) {
> + /*
> +  * It has to be a top calling when it is run from
> +  * process context.
> +  */
> + WARN_ON(this_cpu_read(bio_end_list));
> + __bio_endio(bio);
> + return;
> + }
> +
> + local_irq_save(flags);
> + bl = __this_cpu_read(bio_end_list);
> + if (!bl) {
> + struct bio_list bl_in_stack;
> +
> + bl = _in_stack;
> + bio_list_init(bl);
> + __this_cpu_write(bio_end_list, bl);

The patch seems to make sense, but this bit bothers me.
You are expecting bl_in_stack to still be usable after this block of
code completes.  While it probably is, I don't think it is a good idea
to depend on it.
If you move the "struct bio_list bl_in_stack" to the top of the function
I would be a lot happier.

Or you could change the code to:

   if (bl) {
   bio_list_add(bl, bio);
   } else {
   struct bio_list bl_in_stack;
   ... use bl_in_stack,
   while loop
   set bio_end_list to NULL
   }

and the code flow would all be must clearer.

Thanks,
NeilBrown

> + } else {
> + bio_list_add(bl, bio);
> + goto out;
> + }
> +
> + while (bio) {
> + local_irq_restore(flags);
> + __bio_endio(bio);
> + local_irq_save(flags);
> +> +  bio = bio_list_pop(bl);
> + }
> + __this_cpu_write(bio_end_list, NULL);
> + out:
> + local_irq_restore(flags);
> +}
> +
>  /**
>   * bio_endio - end I/O on a bio
>   * @bio: bio
> @@ -1765,8 +1819,7 @@ again:
>   goto again;
>   }
>  
> - if (bio->bi_end_io)
> - bio->bi_end_io(bio);
> + unwind_bio_endio(bio);
>  }
>  EXPORT_SYMBOL(bio_endio);
>  
> -- 
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


signature.asc
Description: PGP signature

Re: [PATCH v2 3/3] block: avoid to call .bi_end_io() recursively

[NeilBrown]

On Wed, Apr 27 2016, Ming Lei wrote:

> There were reports about heavy stack use by recursive calling
> .bi_end_io()([1][2][3]). For example, more than 16K stack is
> consumed in a single bio complete path[3], and in [2] stack
> overflow can be triggered if 20 nested dm-crypt is used.
>
> Also patches[1] [2] [3] were posted for addressing the issue,
> but never be merged. And the idea in these patches is basically
> similar, all serializes the recursive calling of .bi_end_io() by
> percpu list.
>
> This patch still takes the same idea, but uses bio_list to
> implement it, which turns out more simple and the code becomes
> more readable meantime.
>
> One corner case which wasn't covered before is that
> bi_endio() may be scheduled to run in process context(such
> as btrfs), and this patch just bypasses the optimizing for
> that case because one new context should have enough stack space,
> and this approach isn't capable of optimizing it too because
> there isn't easy way to get a per-task linked list head.
>
> xfstests(-g auto) is run with this patch and no regression is
> found on ext4, xfs and btrfs.
>
> [1] http://marc.info/?t=12142850204=1=2
> [2] http://marc.info/?l=dm-devel=139595190620008=2
> [3] http://marc.info/?t=14597464411=1=2
>
> Cc: Shaun Tancheff 
> Cc: Christoph Hellwig 
> Cc: Mikulas Patocka 
> Cc: Alan Cox 
> Cc: Neil Brown 
> Cc: Liu Bo 
> Signed-off-by: Ming Lei 
> ---
>  block/bio.c | 57 +++--
>  1 file changed, 55 insertions(+), 2 deletions(-)
>
> diff --git a/block/bio.c b/block/bio.c
> index 807d25e..6b4ca7b 100644
> --- a/block/bio.c
> +++ b/block/bio.c
> @@ -68,6 +68,8 @@ static DEFINE_MUTEX(bio_slab_lock);
>  static struct bio_slab *bio_slabs;
>  static unsigned int bio_slab_nr, bio_slab_max;
>  
> +static DEFINE_PER_CPU(struct bio_list *, bio_end_list) = { NULL };
> +
>  static struct kmem_cache *bio_find_or_create_slab(unsigned int extra_size)
>  {
>   unsigned int sz = sizeof(struct bio) + extra_size;
> @@ -1737,6 +1739,58 @@ static inline bool bio_remaining_done(struct bio *bio)
>   return false;
>  }
>  
> +static void __bio_endio(struct bio *bio)
> +{
> + if (bio->bi_end_io)
> + bio->bi_end_io(bio);
> +}
> +
> +/* disable local irq when manipulating the percpu bio_list */
> +static void unwind_bio_endio(struct bio *bio)
> +{
> + struct bio_list *bl;
> + unsigned long flags;
> +
> + /*
> +  * We can't optimize if bi_endio() is scheduled to run from
> +  * process context because there isn't easy way to get a
> +  * per-task bio list head or allocate a per-task variable.
> +  */
> + if (!in_interrupt()) {
> + /*
> +  * It has to be a top calling when it is run from
> +  * process context.
> +  */
> + WARN_ON(this_cpu_read(bio_end_list));
> + __bio_endio(bio);
> + return;
> + }
> +
> + local_irq_save(flags);
> + bl = __this_cpu_read(bio_end_list);
> + if (!bl) {
> + struct bio_list bl_in_stack;
> +
> + bl = _in_stack;
> + bio_list_init(bl);
> + __this_cpu_write(bio_end_list, bl);

The patch seems to make sense, but this bit bothers me.
You are expecting bl_in_stack to still be usable after this block of
code completes.  While it probably is, I don't think it is a good idea
to depend on it.
If you move the "struct bio_list bl_in_stack" to the top of the function
I would be a lot happier.

Or you could change the code to:

   if (bl) {
   bio_list_add(bl, bio);
   } else {
   struct bio_list bl_in_stack;
   ... use bl_in_stack,
   while loop
   set bio_end_list to NULL
   }

and the code flow would all be must clearer.

Thanks,
NeilBrown

> + } else {
> + bio_list_add(bl, bio);
> + goto out;
> + }
> +
> + while (bio) {
> + local_irq_restore(flags);
> + __bio_endio(bio);
> + local_irq_save(flags);
> +> +  bio = bio_list_pop(bl);
> + }
> + __this_cpu_write(bio_end_list, NULL);
> + out:
> + local_irq_restore(flags);
> +}
> +
>  /**
>   * bio_endio - end I/O on a bio
>   * @bio: bio
> @@ -1765,8 +1819,7 @@ again:
>   goto again;
>   }
>  
> - if (bio->bi_end_io)
> - bio->bi_end_io(bio);
> + unwind_bio_endio(bio);
>  }
>  EXPORT_SYMBOL(bio_endio);
>  
> -- 
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


signature.asc
Description: PGP signature

[PATCH v2 1/3] fs: direct-io: handle error in dio_end_io()

[Ming Lei]

If error is passed to dio_end_io(), it should have been
dealt with. Unfortunately current code just ignores that
silently.

Only btrfs uses dio_end_io().

Signed-off-by: Ming Lei 
---
 fs/direct-io.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/direct-io.c b/fs/direct-io.c
index 4720377..a8dd60a 100644
--- a/fs/direct-io.c
+++ b/fs/direct-io.c
@@ -352,6 +352,9 @@ void dio_end_io(struct bio *bio, int error)
 {
struct dio *dio = bio->bi_private;
 
+   if (!bio->bi_error)
+   bio->bi_error = error;
+
if (dio->is_async)
dio_bio_end_aio(bio);
else
-- 
1.9.1

[PATCH v2 1/3] fs: direct-io: handle error in dio_end_io()

[Ming Lei]

If error is passed to dio_end_io(), it should have been
dealt with. Unfortunately current code just ignores that
silently.

Only btrfs uses dio_end_io().

Signed-off-by: Ming Lei 
---
 fs/direct-io.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/direct-io.c b/fs/direct-io.c
index 4720377..a8dd60a 100644
--- a/fs/direct-io.c
+++ b/fs/direct-io.c
@@ -352,6 +352,9 @@ void dio_end_io(struct bio *bio, int error)
 {
struct dio *dio = bio->bi_private;
 
+   if (!bio->bi_error)
+   bio->bi_error = error;
+
if (dio->is_async)
dio_bio_end_aio(bio);
else
-- 
1.9.1

[PATCH v2 2/3] fs: direct-io: call .bi_end_io via bio_endio()

[Ming Lei]

bio_endio() is the graceful way to complete one bio.

Signed-off-by: Ming Lei 
---
 fs/direct-io.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/fs/direct-io.c b/fs/direct-io.c
index a8dd60a..0a35e51 100644
--- a/fs/direct-io.c
+++ b/fs/direct-io.c
@@ -350,15 +350,10 @@ static void dio_bio_end_io(struct bio *bio)
  */
 void dio_end_io(struct bio *bio, int error)
 {
-   struct dio *dio = bio->bi_private;
-
if (!bio->bi_error)
bio->bi_error = error;
 
-   if (dio->is_async)
-   dio_bio_end_aio(bio);
-   else
-   dio_bio_end_io(bio);
+   bio_endio(bio);
 }
 EXPORT_SYMBOL_GPL(dio_end_io);
 
-- 
1.9.1

[PATCH v2 3/3] block: avoid to call .bi_end_io() recursively

[Ming Lei]

There were reports about heavy stack use by recursive calling
.bi_end_io()([1][2][3]). For example, more than 16K stack is
consumed in a single bio complete path[3], and in [2] stack
overflow can be triggered if 20 nested dm-crypt is used.

Also patches[1] [2] [3] were posted for addressing the issue,
but never be merged. And the idea in these patches is basically
similar, all serializes the recursive calling of .bi_end_io() by
percpu list.

This patch still takes the same idea, but uses bio_list to
implement it, which turns out more simple and the code becomes
more readable meantime.

One corner case which wasn't covered before is that
bi_endio() may be scheduled to run in process context(such
as btrfs), and this patch just bypasses the optimizing for
that case because one new context should have enough stack space,
and this approach isn't capable of optimizing it too because
there isn't easy way to get a per-task linked list head.

xfstests(-g auto) is run with this patch and no regression is
found on ext4, xfs and btrfs.

[1] http://marc.info/?t=12142850204=1=2
[2] http://marc.info/?l=dm-devel=139595190620008=2
[3] http://marc.info/?t=14597464411=1=2

Cc: Shaun Tancheff 
Cc: Christoph Hellwig 
Cc: Mikulas Patocka 
Cc: Alan Cox 
Cc: Neil Brown 
Cc: Liu Bo 
Signed-off-by: Ming Lei 
---
 block/bio.c | 57 +++--
 1 file changed, 55 insertions(+), 2 deletions(-)

diff --git a/block/bio.c b/block/bio.c
index 807d25e..6b4ca7b 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -68,6 +68,8 @@ static DEFINE_MUTEX(bio_slab_lock);
 static struct bio_slab *bio_slabs;
 static unsigned int bio_slab_nr, bio_slab_max;
 
+static DEFINE_PER_CPU(struct bio_list *, bio_end_list) = { NULL };
+
 static struct kmem_cache *bio_find_or_create_slab(unsigned int extra_size)
 {
unsigned int sz = sizeof(struct bio) + extra_size;
@@ -1737,6 +1739,58 @@ static inline bool bio_remaining_done(struct bio *bio)
return false;
 }
 
+static void __bio_endio(struct bio *bio)
+{
+   if (bio->bi_end_io)
+   bio->bi_end_io(bio);
+}
+
+/* disable local irq when manipulating the percpu bio_list */
+static void unwind_bio_endio(struct bio *bio)
+{
+   struct bio_list *bl;
+   unsigned long flags;
+
+   /*
+* We can't optimize if bi_endio() is scheduled to run from
+* process context because there isn't easy way to get a
+* per-task bio list head or allocate a per-task variable.
+*/
+   if (!in_interrupt()) {
+   /*
+* It has to be a top calling when it is run from
+* process context.
+*/
+   WARN_ON(this_cpu_read(bio_end_list));
+   __bio_endio(bio);
+   return;
+   }
+
+   local_irq_save(flags);
+   bl = __this_cpu_read(bio_end_list);
+   if (!bl) {
+   struct bio_list bl_in_stack;
+
+   bl = _in_stack;
+   bio_list_init(bl);
+   __this_cpu_write(bio_end_list, bl);
+   } else {
+   bio_list_add(bl, bio);
+   goto out;
+   }
+
+   while (bio) {
+   local_irq_restore(flags);
+   __bio_endio(bio);
+   local_irq_save(flags);
+
+   bio = bio_list_pop(bl);
+   }
+   __this_cpu_write(bio_end_list, NULL);
+ out:
+   local_irq_restore(flags);
+}
+
 /**
  * bio_endio - end I/O on a bio
  * @bio:   bio
@@ -1765,8 +1819,7 @@ again:
goto again;
}
 
-   if (bio->bi_end_io)
-   bio->bi_end_io(bio);
+   unwind_bio_endio(bio);
 }
 EXPORT_SYMBOL(bio_endio);
 
-- 
1.9.1

[PATCH v2 2/3] fs: direct-io: call .bi_end_io via bio_endio()

[Ming Lei]

bio_endio() is the graceful way to complete one bio.

Signed-off-by: Ming Lei 
---
 fs/direct-io.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/fs/direct-io.c b/fs/direct-io.c
index a8dd60a..0a35e51 100644
--- a/fs/direct-io.c
+++ b/fs/direct-io.c
@@ -350,15 +350,10 @@ static void dio_bio_end_io(struct bio *bio)
  */
 void dio_end_io(struct bio *bio, int error)
 {
-   struct dio *dio = bio->bi_private;
-
if (!bio->bi_error)
bio->bi_error = error;
 
-   if (dio->is_async)
-   dio_bio_end_aio(bio);
-   else
-   dio_bio_end_io(bio);
+   bio_endio(bio);
 }
 EXPORT_SYMBOL_GPL(dio_end_io);
 
-- 
1.9.1

[PATCH v2 3/3] block: avoid to call .bi_end_io() recursively

[Ming Lei]

There were reports about heavy stack use by recursive calling
.bi_end_io()([1][2][3]). For example, more than 16K stack is
consumed in a single bio complete path[3], and in [2] stack
overflow can be triggered if 20 nested dm-crypt is used.

Also patches[1] [2] [3] were posted for addressing the issue,
but never be merged. And the idea in these patches is basically
similar, all serializes the recursive calling of .bi_end_io() by
percpu list.

This patch still takes the same idea, but uses bio_list to
implement it, which turns out more simple and the code becomes
more readable meantime.

One corner case which wasn't covered before is that
bi_endio() may be scheduled to run in process context(such
as btrfs), and this patch just bypasses the optimizing for
that case because one new context should have enough stack space,
and this approach isn't capable of optimizing it too because
there isn't easy way to get a per-task linked list head.

xfstests(-g auto) is run with this patch and no regression is
found on ext4, xfs and btrfs.

[1] http://marc.info/?t=12142850204=1=2
[2] http://marc.info/?l=dm-devel=139595190620008=2
[3] http://marc.info/?t=14597464411=1=2

Cc: Shaun Tancheff 
Cc: Christoph Hellwig 
Cc: Mikulas Patocka 
Cc: Alan Cox 
Cc: Neil Brown 
Cc: Liu Bo 
Signed-off-by: Ming Lei 
---
 block/bio.c | 57 +++--
 1 file changed, 55 insertions(+), 2 deletions(-)

diff --git a/block/bio.c b/block/bio.c
index 807d25e..6b4ca7b 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -68,6 +68,8 @@ static DEFINE_MUTEX(bio_slab_lock);
 static struct bio_slab *bio_slabs;
 static unsigned int bio_slab_nr, bio_slab_max;
 
+static DEFINE_PER_CPU(struct bio_list *, bio_end_list) = { NULL };
+
 static struct kmem_cache *bio_find_or_create_slab(unsigned int extra_size)
 {
unsigned int sz = sizeof(struct bio) + extra_size;
@@ -1737,6 +1739,58 @@ static inline bool bio_remaining_done(struct bio *bio)
return false;
 }
 
+static void __bio_endio(struct bio *bio)
+{
+   if (bio->bi_end_io)
+   bio->bi_end_io(bio);
+}
+
+/* disable local irq when manipulating the percpu bio_list */
+static void unwind_bio_endio(struct bio *bio)
+{
+   struct bio_list *bl;
+   unsigned long flags;
+
+   /*
+* We can't optimize if bi_endio() is scheduled to run from
+* process context because there isn't easy way to get a
+* per-task bio list head or allocate a per-task variable.
+*/
+   if (!in_interrupt()) {
+   /*
+* It has to be a top calling when it is run from
+* process context.
+*/
+   WARN_ON(this_cpu_read(bio_end_list));
+   __bio_endio(bio);
+   return;
+   }
+
+   local_irq_save(flags);
+   bl = __this_cpu_read(bio_end_list);
+   if (!bl) {
+   struct bio_list bl_in_stack;
+
+   bl = _in_stack;
+   bio_list_init(bl);
+   __this_cpu_write(bio_end_list, bl);
+   } else {
+   bio_list_add(bl, bio);
+   goto out;
+   }
+
+   while (bio) {
+   local_irq_restore(flags);
+   __bio_endio(bio);
+   local_irq_save(flags);
+
+   bio = bio_list_pop(bl);
+   }
+   __this_cpu_write(bio_end_list, NULL);
+ out:
+   local_irq_restore(flags);
+}
+
 /**
  * bio_endio - end I/O on a bio
  * @bio:   bio
@@ -1765,8 +1819,7 @@ again:
goto again;
}
 
-   if (bio->bi_end_io)
-   bio->bi_end_io(bio);
+   unwind_bio_endio(bio);
 }
 EXPORT_SYMBOL(bio_endio);
 
-- 
1.9.1

[PATCH v2 0/3] block: avoid to call .bi_end_io() recursively

[Ming Lei]

Hi,

The 1st patch handles bio error in dio_end_io() which is only
used by btrfs.

The 2nd patch uses bio_endio() to call .bi_end_io() in dio_end_io().

The 3rd patch avoids to call .bi_end_io recursively in complete path.

xfstests(-g auto) is run over ext4, xfs and btrfs with this patchset
and no regression is reported.

With this patchset, lots of stack space can be saved in bio complete
path. Even there was stack overflow report in bio complete path, see
details in 3/3 commit log.

V2:
- introduce patch 1 & 2
- deal with running bio_endio() from process context, and
makes generic/323 & generic/224 of xfstests happy on btrfs

V1:
- change to RFC
- fix when unwind_bio_endio() is called recursively
- run xfstest again: no regression found on ext4,
but generic/323 and generic/224 cause kernel oops


Ming Lei (3):
  fs: direct-io: handle error in dio_end_io()
  fs: direct-io: call .bi_end_io via bio_endio()
  bflock: avoid to call .bi_end_io() recursively

 block/bio.c| 57 +++--
 fs/direct-io.c |  8 +++-
 2 files changed, 58 insertions(+), 7 deletions(-)

-- 
1.9.1

[PATCH v2 0/3] block: avoid to call .bi_end_io() recursively

[Ming Lei]

Hi,

The 1st patch handles bio error in dio_end_io() which is only
used by btrfs.

The 2nd patch uses bio_endio() to call .bi_end_io() in dio_end_io().

The 3rd patch avoids to call .bi_end_io recursively in complete path.

xfstests(-g auto) is run over ext4, xfs and btrfs with this patchset
and no regression is reported.

With this patchset, lots of stack space can be saved in bio complete
path. Even there was stack overflow report in bio complete path, see
details in 3/3 commit log.

V2:
- introduce patch 1 & 2
- deal with running bio_endio() from process context, and
makes generic/323 & generic/224 of xfstests happy on btrfs

V1:
- change to RFC
- fix when unwind_bio_endio() is called recursively
- run xfstest again: no regression found on ext4,
but generic/323 and generic/224 cause kernel oops


Ming Lei (3):
  fs: direct-io: handle error in dio_end_io()
  fs: direct-io: call .bi_end_io via bio_endio()
  bflock: avoid to call .bi_end_io() recursively

 block/bio.c| 57 +++--
 fs/direct-io.c |  8 +++-
 2 files changed, 58 insertions(+), 7 deletions(-)

-- 
1.9.1

linux-next: manual merge of the dt-rh tree with the tegra tree

[Stephen Rothwell]

Hi Rob,

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

  Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt

between commit:

  53cafb93da6f ("dt-bindings: Add documentation for GM20B GPU")

from the tegra tree and commit:

  f43521e95211 ("dt-bindings: tegra: Remove 0, prefix from unit-addresses")

from the dt-rh tree.

I fixed it up (they were very similar) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the dt-rh tree with the tegra tree

[Stephen Rothwell]

Hi Rob,

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

  Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt

between commit:

  53cafb93da6f ("dt-bindings: Add documentation for GM20B GPU")

from the tegra tree and commit:

  f43521e95211 ("dt-bindings: tegra: Remove 0, prefix from unit-addresses")

from the dt-rh tree.

I fixed it up (they were very similar) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH] iio: tmp006: Set correct iio name

[Yong Li]

Thanks for your mails. Is it possible to just merge this patch, then
test if there is any application is using it?  Considering almost all
other I2C devices are using the correct ID name, it should be low
risky

Yong

2016-04-26 23:21 GMT+08:00 Daniel Baluta :
> On Tue, Apr 26, 2016 at 4:14 PM, Yong Li  wrote:
>> I am thinking if there is any application is using this incorrect
>> name, the application should be fix too
>
> The rule is: "Don't break the userspace ABI". So, if we got this wrong
> from the beginning we are stuck with this name.
>
> The only thing that can save the situation is to know that there is no
> application relying on the name :).

Re: [PATCH] iio: tmp006: Set correct iio name

[Yong Li]

Thanks for your mails. Is it possible to just merge this patch, then
test if there is any application is using it?  Considering almost all
other I2C devices are using the correct ID name, it should be low
risky

Yong

2016-04-26 23:21 GMT+08:00 Daniel Baluta :
> On Tue, Apr 26, 2016 at 4:14 PM, Yong Li  wrote:
>> I am thinking if there is any application is using this incorrect
>> name, the application should be fix too
>
> The rule is: "Don't break the userspace ABI". So, if we got this wrong
> from the beginning we are stuck with this name.
>
> The only thing that can save the situation is to know that there is no
> application relying on the name :).

Re: [PATCH 3.2 000/115] 3.2.80-rc1 review

[Guenter Roeck]

On 04/26/2016 04:02 PM, Ben Hutchings wrote:

This is the start of the stable review cycle for the 3.2.80 release.
There are 115 patches in this series, which will be posted as responses
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sat Apr 30 22:00:00 UTC 2016.
Anything received after that time might be too late.



Build results:
total: 94 pass: 94 fail: 0
Qemu test results:
total: 61 pass: 61 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

Re: [PATCH 3.2 000/115] 3.2.80-rc1 review

[Guenter Roeck]

On 04/26/2016 04:02 PM, Ben Hutchings wrote:

This is the start of the stable review cycle for the 3.2.80 release.
There are 115 patches in this series, which will be posted as responses
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sat Apr 30 22:00:00 UTC 2016.
Anything received after that time might be too late.



Build results:
total: 94 pass: 94 fail: 0
Qemu test results:
total: 61 pass: 61 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

Re: [PATCH v5 09/21] IB/hns: Add hca support

[oulijun]

On 2016/4/26 22:18, Leon Romanovsky wrote:
> On Tue, Apr 26, 2016 at 02:34:44PM +0800, oulijun wrote:
>> On 2016/4/24 15:54, Leon Romanovsky wrote:
>>> On Sat, Apr 23, 2016 at 06:26:47PM +0800, Lijun Ou wrote:
 This patch mainly setup hca for RoCE. it will do a series of
 initial works as follows:
   1. init uar table, allocate uar resource
   2. init pd table
   3. init cq table
   4. init mr table
   5. init qp table

 Signed-off-by: Lijun Ou 
 Signed-off-by: Wei Hu(Xavier) 
 ---
  drivers/infiniband/hw/hns/hns_roce_alloc.c  | 104 
  drivers/infiniband/hw/hns/hns_roce_cq.c |  25 
  drivers/infiniband/hw/hns/hns_roce_device.h |  69 ++
  drivers/infiniband/hw/hns/hns_roce_eq.c |   1 -
  drivers/infiniband/hw/hns/hns_roce_icm.c|  88 +
  drivers/infiniband/hw/hns/hns_roce_icm.h|   9 ++
  drivers/infiniband/hw/hns/hns_roce_main.c   |  79 
  drivers/infiniband/hw/hns/hns_roce_mr.c | 187 
 
  drivers/infiniband/hw/hns/hns_roce_pd.c |  65 ++
  drivers/infiniband/hw/hns/hns_roce_qp.c |  30 +
  10 files changed, 656 insertions(+), 1 deletion(-)
  create mode 100644 drivers/infiniband/hw/hns/hns_roce_alloc.c
  create mode 100644 drivers/infiniband/hw/hns/hns_roce_mr.c
  create mode 100644 drivers/infiniband/hw/hns/hns_roce_pd.c

 diff --git a/drivers/infiniband/hw/hns/hns_roce_alloc.c 
 b/drivers/infiniband/hw/hns/hns_roce_alloc.c
 new file mode 100644
 index 000..0c76f1b
 --- /dev/null
 +++ b/drivers/infiniband/hw/hns/hns_roce_alloc.c
 @@ -0,0 +1,104 @@
 +/*
 + * Copyright (c) 2016 Hisilicon Limited.
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License as published by
 + * the Free Software Foundation; either version 2 of the License, or
 + * (at your option) any later version.
 + */
 +
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include "hns_roce_device.h"
 +
 +int hns_roce_bitmap_alloc(struct hns_roce_bitmap *bitmap, u32 *obj)
 +{
 +  int ret = 0;
 +
 +  spin_lock(>lock);
 +  *obj = find_next_zero_bit(bitmap->table, bitmap->max, bitmap->last);
 +  if (*obj >= bitmap->max) {
 +  bitmap->top = (bitmap->top + bitmap->max + bitmap->reserved_top)
 + & bitmap->mask;
 +  *obj = find_first_zero_bit(bitmap->table, bitmap->max);
>>>
>>> find_first_zero_bit function returns "unsigned long" which may or may
>>> not be equal to u32 on some architectures.
>>>
>> Hi Leon,
>> I appreciate your keen eye. this code is meant for ARM64bit therefore 
>> should run corretly for 64-bit AARCH64.
>> I will consider changing it as part of good partice and better portability "
>> I will give a primary plan to modified it.
>> for example:
>> *obj = (u32)find_next_zero_bit(bitmap->table, bitmap->max, bitmap->last);
>> Beause the max size of bitmap->table is u32 in current version.
>>
>> int hns_roce_bitmap_init(struct hns_roce_bitmap *bitmap, u32 num, u32 mask,
>>   u32 reserved_bot, u32 reserved_top)
>> {
>>  u32 i;
>>
>>  if (num != roundup_pow_of_two(num))
>>  return -EINVAL;
>>
>>  bitmap->last = 0;
>>  bitmap->top = 0;
>>  bitmap->max = num - reserved_top;
>>  bitmap->mask = mask;
>>  bitmap->reserved_top = reserved_top;
>>  spin_lock_init(>lock);
>>  bitmap->table = kcalloc(BITS_TO_LONGS(bitmap->max), sizeof(long),
>>  GFP_KERNEL);
>>
>> Is this plan ok?
> 
> No,
> You are submitting new driver, please do it properly (without casting)
> from the beginning.
> 
oh, i see. I will give a better plan to modify it.

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

Re: [PATCH v5 09/21] IB/hns: Add hca support

[oulijun]

On 2016/4/26 22:18, Leon Romanovsky wrote:
> On Tue, Apr 26, 2016 at 02:34:44PM +0800, oulijun wrote:
>> On 2016/4/24 15:54, Leon Romanovsky wrote:
>>> On Sat, Apr 23, 2016 at 06:26:47PM +0800, Lijun Ou wrote:
 This patch mainly setup hca for RoCE. it will do a series of
 initial works as follows:
   1. init uar table, allocate uar resource
   2. init pd table
   3. init cq table
   4. init mr table
   5. init qp table

 Signed-off-by: Lijun Ou 
 Signed-off-by: Wei Hu(Xavier) 
 ---
  drivers/infiniband/hw/hns/hns_roce_alloc.c  | 104 
  drivers/infiniband/hw/hns/hns_roce_cq.c |  25 
  drivers/infiniband/hw/hns/hns_roce_device.h |  69 ++
  drivers/infiniband/hw/hns/hns_roce_eq.c |   1 -
  drivers/infiniband/hw/hns/hns_roce_icm.c|  88 +
  drivers/infiniband/hw/hns/hns_roce_icm.h|   9 ++
  drivers/infiniband/hw/hns/hns_roce_main.c   |  79 
  drivers/infiniband/hw/hns/hns_roce_mr.c | 187 
 
  drivers/infiniband/hw/hns/hns_roce_pd.c |  65 ++
  drivers/infiniband/hw/hns/hns_roce_qp.c |  30 +
  10 files changed, 656 insertions(+), 1 deletion(-)
  create mode 100644 drivers/infiniband/hw/hns/hns_roce_alloc.c
  create mode 100644 drivers/infiniband/hw/hns/hns_roce_mr.c
  create mode 100644 drivers/infiniband/hw/hns/hns_roce_pd.c

 diff --git a/drivers/infiniband/hw/hns/hns_roce_alloc.c 
 b/drivers/infiniband/hw/hns/hns_roce_alloc.c
 new file mode 100644
 index 000..0c76f1b
 --- /dev/null
 +++ b/drivers/infiniband/hw/hns/hns_roce_alloc.c
 @@ -0,0 +1,104 @@
 +/*
 + * Copyright (c) 2016 Hisilicon Limited.
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License as published by
 + * the Free Software Foundation; either version 2 of the License, or
 + * (at your option) any later version.
 + */
 +
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include "hns_roce_device.h"
 +
 +int hns_roce_bitmap_alloc(struct hns_roce_bitmap *bitmap, u32 *obj)
 +{
 +  int ret = 0;
 +
 +  spin_lock(>lock);
 +  *obj = find_next_zero_bit(bitmap->table, bitmap->max, bitmap->last);
 +  if (*obj >= bitmap->max) {
 +  bitmap->top = (bitmap->top + bitmap->max + bitmap->reserved_top)
 + & bitmap->mask;
 +  *obj = find_first_zero_bit(bitmap->table, bitmap->max);
>>>
>>> find_first_zero_bit function returns "unsigned long" which may or may
>>> not be equal to u32 on some architectures.
>>>
>> Hi Leon,
>> I appreciate your keen eye. this code is meant for ARM64bit therefore 
>> should run corretly for 64-bit AARCH64.
>> I will consider changing it as part of good partice and better portability "
>> I will give a primary plan to modified it.
>> for example:
>> *obj = (u32)find_next_zero_bit(bitmap->table, bitmap->max, bitmap->last);
>> Beause the max size of bitmap->table is u32 in current version.
>>
>> int hns_roce_bitmap_init(struct hns_roce_bitmap *bitmap, u32 num, u32 mask,
>>   u32 reserved_bot, u32 reserved_top)
>> {
>>  u32 i;
>>
>>  if (num != roundup_pow_of_two(num))
>>  return -EINVAL;
>>
>>  bitmap->last = 0;
>>  bitmap->top = 0;
>>  bitmap->max = num - reserved_top;
>>  bitmap->mask = mask;
>>  bitmap->reserved_top = reserved_top;
>>  spin_lock_init(>lock);
>>  bitmap->table = kcalloc(BITS_TO_LONGS(bitmap->max), sizeof(long),
>>  GFP_KERNEL);
>>
>> Is this plan ok?
> 
> No,
> You are submitting new driver, please do it properly (without casting)
> from the beginning.
> 
oh, i see. I will give a better plan to modify it.

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

Re: [PATCH v5 09/21] IB/hns: Add hca support

[oulijun]

On 2016/4/26 22:25, Jiri Pirko wrote:
> Tue, Apr 26, 2016 at 04:18:21PM CEST, l...@kernel.org wrote:
>> On Tue, Apr 26, 2016 at 02:34:44PM +0800, oulijun wrote:
>>> On 2016/4/24 15:54, Leon Romanovsky wrote:
> 
> 
> 
> +int hns_roce_bitmap_alloc(struct hns_roce_bitmap *bitmap, u32 *obj)
> +{
> + int ret = 0;
> +
> + spin_lock(>lock);
> + *obj = find_next_zero_bit(bitmap->table, bitmap->max, bitmap->last);
> + if (*obj >= bitmap->max) {
> + bitmap->top = (bitmap->top + bitmap->max + bitmap->reserved_top)
> +& bitmap->mask;
> + *obj = find_first_zero_bit(bitmap->table, bitmap->max);

 find_first_zero_bit function returns "unsigned long" which may or may
 not be equal to u32 on some architectures.

>>> Hi Leon,
>>> I appreciate your keen eye. this code is meant for ARM64bit therefore 
>>> should run corretly for 64-bit AARCH64.
> 
> The driver should run correctly on any arch.
> 
 Hi Jiri Pirko,
Our driver run in ARM64 platform by depending on Kconfig. It will be 
configure in Kconfig file.

Thanks
Lijun Ou
> 
>>> I will consider changing it as part of good partice and better portability "
>>> I will give a primary plan to modified it.
>>> for example:
>>> *obj = (u32)find_next_zero_bit(bitmap->table, bitmap->max, 
>>> bitmap->last);
>>> Beause the max size of bitmap->table is u32 in current version.
>>>
>>> int hns_roce_bitmap_init(struct hns_roce_bitmap *bitmap, u32 num, u32 mask,
>>>  u32 reserved_bot, u32 reserved_top)
>>> {
>>> u32 i;
>>>
>>> if (num != roundup_pow_of_two(num))
>>> return -EINVAL;
>>>
>>> bitmap->last = 0;
>>> bitmap->top = 0;
>>> bitmap->max = num - reserved_top;
>>> bitmap->mask = mask;
>>> bitmap->reserved_top = reserved_top;
>>> spin_lock_init(>lock);
>>> bitmap->table = kcalloc(BITS_TO_LONGS(bitmap->max), sizeof(long),
>>> GFP_KERNEL);
>>>
>>> Is this plan ok?
>>
>> No,
>> You are submitting new driver, please do it properly (without casting)
>>from the beginning.
>>
>>>
>>> Thanks
>>> Lijun Ou
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 
> .
> 

Re: [PATCH v5 09/21] IB/hns: Add hca support

[oulijun]

On 2016/4/26 22:25, Jiri Pirko wrote:
> Tue, Apr 26, 2016 at 04:18:21PM CEST, l...@kernel.org wrote:
>> On Tue, Apr 26, 2016 at 02:34:44PM +0800, oulijun wrote:
>>> On 2016/4/24 15:54, Leon Romanovsky wrote:
> 
> 
> 
> +int hns_roce_bitmap_alloc(struct hns_roce_bitmap *bitmap, u32 *obj)
> +{
> + int ret = 0;
> +
> + spin_lock(>lock);
> + *obj = find_next_zero_bit(bitmap->table, bitmap->max, bitmap->last);
> + if (*obj >= bitmap->max) {
> + bitmap->top = (bitmap->top + bitmap->max + bitmap->reserved_top)
> +& bitmap->mask;
> + *obj = find_first_zero_bit(bitmap->table, bitmap->max);

 find_first_zero_bit function returns "unsigned long" which may or may
 not be equal to u32 on some architectures.

>>> Hi Leon,
>>> I appreciate your keen eye. this code is meant for ARM64bit therefore 
>>> should run corretly for 64-bit AARCH64.
> 
> The driver should run correctly on any arch.
> 
 Hi Jiri Pirko,
Our driver run in ARM64 platform by depending on Kconfig. It will be 
configure in Kconfig file.

Thanks
Lijun Ou
> 
>>> I will consider changing it as part of good partice and better portability "
>>> I will give a primary plan to modified it.
>>> for example:
>>> *obj = (u32)find_next_zero_bit(bitmap->table, bitmap->max, 
>>> bitmap->last);
>>> Beause the max size of bitmap->table is u32 in current version.
>>>
>>> int hns_roce_bitmap_init(struct hns_roce_bitmap *bitmap, u32 num, u32 mask,
>>>  u32 reserved_bot, u32 reserved_top)
>>> {
>>> u32 i;
>>>
>>> if (num != roundup_pow_of_two(num))
>>> return -EINVAL;
>>>
>>> bitmap->last = 0;
>>> bitmap->top = 0;
>>> bitmap->max = num - reserved_top;
>>> bitmap->mask = mask;
>>> bitmap->reserved_top = reserved_top;
>>> spin_lock_init(>lock);
>>> bitmap->table = kcalloc(BITS_TO_LONGS(bitmap->max), sizeof(long),
>>> GFP_KERNEL);
>>>
>>> Is this plan ok?
>>
>> No,
>> You are submitting new driver, please do it properly (without casting)
>>from the beginning.
>>
>>>
>>> Thanks
>>> Lijun Ou
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 
> .
> 

Re: [PATCH] parisc: fix a bug when syscall number of tracee is __NR_Linux_syscalls

[Dmitry V. Levin]

On Tue, Apr 26, 2016 at 10:45:11PM -0400, Mike Frysinger wrote:
> On 27 Apr 2016 04:56, Dmitry V. Levin wrote:
> > Do not load one entry beyond the end of the syscall table when the
> > syscall number of a traced process equals to __NR_Linux_syscalls.
> > Similar bug with regular processes was fixed by commit 3bb457af4fa8
> > ("[PARISC] Fix bug when syscall nr is __NR_Linux_syscalls").
> > 
> > This bug was found by strace test suite.
> > 
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Dmitry V. Levin 
> > ---
> >  arch/parisc/kernel/syscall.S | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/parisc/kernel/syscall.S b/arch/parisc/kernel/syscall.S
> > index c976ebf..57b4836 100644
> > --- a/arch/parisc/kernel/syscall.S
> > +++ b/arch/parisc/kernel/syscall.S
> > @@ -344,7 +344,7 @@ tracesys_next:
> >  #endif
> >  
> > cmpib,COND(=),n -1,%r20,tracesys_exit /* seccomp may have returned -1 */
> > -   comiclr,>>= __NR_Linux_syscalls, %r20, %r0
> > +   comiclr,>>  __NR_Linux_syscalls, %r20, %r0
> > b,n .Ltracesys_nosys
> >  
> > LDREGX  %r20(%r19), %r19
> 
> i've deployd your fix to hake, so feel free to give the tests another
> run to try and crash the box :).

With this fix the box no longer crashes.


-- 
ldv


pgpdfCtDW94Mc.pgp
Description: PGP signature

Re: [PATCH] parisc: fix a bug when syscall number of tracee is __NR_Linux_syscalls

[Dmitry V. Levin]

On Tue, Apr 26, 2016 at 10:45:11PM -0400, Mike Frysinger wrote:
> On 27 Apr 2016 04:56, Dmitry V. Levin wrote:
> > Do not load one entry beyond the end of the syscall table when the
> > syscall number of a traced process equals to __NR_Linux_syscalls.
> > Similar bug with regular processes was fixed by commit 3bb457af4fa8
> > ("[PARISC] Fix bug when syscall nr is __NR_Linux_syscalls").
> > 
> > This bug was found by strace test suite.
> > 
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Dmitry V. Levin 
> > ---
> >  arch/parisc/kernel/syscall.S | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/parisc/kernel/syscall.S b/arch/parisc/kernel/syscall.S
> > index c976ebf..57b4836 100644
> > --- a/arch/parisc/kernel/syscall.S
> > +++ b/arch/parisc/kernel/syscall.S
> > @@ -344,7 +344,7 @@ tracesys_next:
> >  #endif
> >  
> > cmpib,COND(=),n -1,%r20,tracesys_exit /* seccomp may have returned -1 */
> > -   comiclr,>>= __NR_Linux_syscalls, %r20, %r0
> > +   comiclr,>>  __NR_Linux_syscalls, %r20, %r0
> > b,n .Ltracesys_nosys
> >  
> > LDREGX  %r20(%r19), %r19
> 
> i've deployd your fix to hake, so feel free to give the tests another
> run to try and crash the box :).

With this fix the box no longer crashes.


-- 
ldv


pgpdfCtDW94Mc.pgp
Description: PGP signature

[PATCH v2 2/9] arm64: tegra: use tegra132-soctherm for Tegra132

[Wei Ni]

The Tegra132 has the specific settings for soctherm,
so change to use campatible "nvidia,tegra132-soctherm" for it.
And adds cpu, gpu, mem and pllx thermal zones.

Signed-off-by: Wei Ni 
---
 arch/arm64/boot/dts/nvidia/tegra132.dtsi | 36 ++--
 1 file changed, 34 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/nvidia/tegra132.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra132.dtsi
index 2013f8916084..e41d8e82d7ed 100644
--- a/arch/arm64/boot/dts/nvidia/tegra132.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra132.dtsi
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 
 / {
compatible = "nvidia,tegra132", "nvidia,tegra124";
@@ -727,8 +728,8 @@
};
 
soctherm: thermal-sensor@700e2000 {
-   compatible = "nvidia,tegra124-soctherm";
-   reg = <0x0 0x700e2000 0x0 0x1000>;
+   compatible = "nvidia,tegra132-soctherm";
+   reg = <0x0 0x700e2000 0x0 0x600>;
interrupts = ;
clocks = <_car TEGRA124_CLK_TSENSOR>,
<_car TEGRA124_CLK_SOC_THERM>;
@@ -738,6 +739,37 @@
#thermal-sensor-cells = <1>;
};
 
+   thermal-zones {
+   cpu {
+   polling-delay-passive = <1000>;
+   polling-delay = <0>;
+
+   thermal-sensors =
+   < TEGRA124_SOCTHERM_SENSOR_CPU>;
+   };
+   mem {
+   polling-delay-passive = <0>;
+   polling-delay = <0>;
+
+   thermal-sensors =
+   < TEGRA124_SOCTHERM_SENSOR_MEM>;
+   };
+   gpu {
+   polling-delay-passive = <1000>;
+   polling-delay = <0>;
+
+   thermal-sensors =
+   < TEGRA124_SOCTHERM_SENSOR_GPU>;
+   };
+   pllx {
+   polling-delay-passive = <0>;
+   polling-delay = <0>;
+
+   thermal-sensors =
+   < TEGRA124_SOCTHERM_SENSOR_PLLX>;
+   };
+   };
+
ahub@7030 {
compatible = "nvidia,tegra124-ahub";
reg = <0x0 0x7030 0x0 0x200>,
-- 
1.9.1

[PATCH v2 6/9] thermal: tegra: add hw-throttle for Tegra132

[Wei Ni]

Tegra132 use CCROC throttle registers to configure
pulse skiper, set these registers to enable throttle
function for Tegra132.

Signed-off-by: Wei Ni 
---
 drivers/thermal/tegra/soctherm.c| 215 +---
 drivers/thermal/tegra/tegra132-soctherm.c   |  17 ++
 include/dt-bindings/thermal/tegra124-soctherm.h |   5 +
 3 files changed, 212 insertions(+), 25 deletions(-)

diff --git a/drivers/thermal/tegra/soctherm.c b/drivers/thermal/tegra/soctherm.c
index e6c4085f876d..900834637464 100644
--- a/drivers/thermal/tegra/soctherm.c
+++ b/drivers/thermal/tegra/soctherm.c
@@ -136,6 +136,21 @@
 #define CAR_SUPER_CCLKG_DIVIDER0x36c
 #define CDIVG_USE_THERM_CONTROLS_MASK  BIT(30)
 
+/* ccroc register offsets needed for enabling HW throttling for Tegra132 */
+#define CCROC_SUPER_CCLKG_DIVIDER  0x024
+
+#define CCROC_GLOBAL_CFG   0x148
+
+#define CCROC_THROT_PSKIP_RAMP_CPU 0x150
+#define CCROC_THROT_PSKIP_RAMP_SEQ_BYPASS_MODE_MASKBIT(31)
+#define CCROC_THROT_PSKIP_RAMP_DURATION_MASK   (0x << 8)
+#define CCROC_THROT_PSKIP_RAMP_STEP_MASK   0xff
+
+#define CCROC_THROT_PSKIP_CTRL_CPU 0x154
+#define CCROC_THROT_PSKIP_CTRL_ENB_MASKBIT(31)
+#define CCROC_THROT_PSKIP_CTRL_DIVIDEND_MASK   (0xff << 8)
+#define CCROC_THROT_PSKIP_CTRL_DIVISOR_MASK0xff
+
 /* get val from register(r) mask bits(m) */
 #define REG_GET_MASK(r, m) (((r) & (m)) >> (ffs(m) - 1))
 /* set val(v) to mask bits(m) of register(r) */
@@ -158,6 +173,13 @@
 #define THROT_DELAY_CTRL(throt)(THROT_DELAY_LITE + \
(THROT_OFFSET * throt))
 
+/* get CCROC_THROT_PSKIP_xxx offset per HIGH/MED/LOW vect*/
+#define CCROC_THROT_OFFSET 0x0c
+#define CCROC_THROT_PSKIP_CTRL_CPU_REG(vect)(CCROC_THROT_PSKIP_CTRL_CPU + \
+   (CCROC_THROT_OFFSET * vect))
+#define CCROC_THROT_PSKIP_RAMP_CPU_REG(vect)(CCROC_THROT_PSKIP_RAMP_CPU + \
+   (CCROC_THROT_OFFSET * vect))
+
 /* get THERMCTL_LEVELx offset per CPU/GPU/MEM/TSENSE rg and LEVEL0~3 lv */
 #define THERMCTL_LVL_REGS_SIZE 0x20
 #define THERMCTL_LVL_REG(rg, lv)   ((rg) + ((lv) * THERMCTL_LVL_REGS_SIZE))
@@ -195,6 +217,7 @@ struct soctherm_throt_cfg {
const char *name;
unsigned int id;
u8 priority;
+   u8 cpu_throt_level;
u32 cpu_throt_depth;
struct thermal_cooling_device *cdev;
bool init;
@@ -206,6 +229,7 @@ struct tegra_soctherm {
struct clk *clock_soctherm;
void __iomem *regs;
void __iomem *clk_regs;
+   void __iomem *ccroc_regs;
 
u32 *calib;
struct thermal_zone_device **thermctl_tzs;
@@ -241,6 +265,31 @@ static inline u32 clk_readl(struct tegra_soctherm *ts, u32 
reg)
return readl(ts->clk_regs + reg);
 }
 
+/**
+ * ccroc_writel() - writes a value to a CCROC register
+ * @ts: pointer to a struct tegra_soctherm
+ * @v: the value to write
+ * @reg: the register offset
+ *
+ * Writes @v to @reg.  No return value.
+ */
+static inline void ccroc_writel(struct tegra_soctherm *ts, u32 value, u32 reg)
+{
+   writel(value, (ts->ccroc_regs + reg));
+}
+
+/**
+ * ccroc_readl() - reads specified register from CCROC IP block
+ * @ts: pointer to a struct tegra_soctherm
+ * @reg: register address to be read
+ *
+ * Return: the value of the register
+ */
+static inline u32 ccroc_readl(struct tegra_soctherm *ts, u32 reg)
+{
+   return readl(ts->ccroc_regs + reg);
+}
+
 static void enable_tsensor(struct tegra_soctherm *tegra, unsigned int i)
 {
const struct tegra_tsensor *sensor = >soc->tsensors[i];
@@ -552,9 +601,6 @@ static int tegra_soctherm_set_hwtrips(struct device *dev,
 sg->name, temperature);
 
 set_throttle:
-   if (ts->soc->use_ccroc)
-   return 0;
-
ret = get_hot_temp(tz, , );
if (ret) {
dev_warn(dev, "throttle: %s: missing hot temperature\n",
@@ -676,9 +722,6 @@ static int regs_show(struct seq_file *s, void *data)
state = REG_GET_MASK(r, SENSOR_TEMP2_MEM_TEMP_MASK);
seq_printf(s, " MEM(%d)\n", translate_temp(state));
 
-   if (ts->soc->use_ccroc)
-   return 0;
-
for (i = 0; i < ts->soc->num_ttgs; i++) {
seq_printf(s, "%s:\n", ttgs[i]->name);
for (level = 0; level < 4; level++) {
@@ -779,12 +822,17 @@ static int regs_show(struct seq_file *s, void *data)
seq_printf(s, "enabled(%d)\n", state);
 
r = readl(ts->regs + CPU_PSKIP_STATUS);
-   state = REG_GET_MASK(r, XPU_PSKIP_STATUS_M_MASK);
-   seq_printf(s, "CPU PSKIP STATUS: M(%d) ", state);
-   state = REG_GET_MASK(r, XPU_PSKIP_STATUS_N_MASK);
-   seq_printf(s, "N(%d) ", state);
-   state = REG_GET_MASK(r, XPU_PSKIP_STATUS_ENABLED_MASK);
-   

[PATCH v2 2/9] arm64: tegra: use tegra132-soctherm for Tegra132

[Wei Ni]

The Tegra132 has the specific settings for soctherm,
so change to use campatible "nvidia,tegra132-soctherm" for it.
And adds cpu, gpu, mem and pllx thermal zones.

Signed-off-by: Wei Ni 
---
 arch/arm64/boot/dts/nvidia/tegra132.dtsi | 36 ++--
 1 file changed, 34 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/nvidia/tegra132.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra132.dtsi
index 2013f8916084..e41d8e82d7ed 100644
--- a/arch/arm64/boot/dts/nvidia/tegra132.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra132.dtsi
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 
 / {
compatible = "nvidia,tegra132", "nvidia,tegra124";
@@ -727,8 +728,8 @@
};
 
soctherm: thermal-sensor@700e2000 {
-   compatible = "nvidia,tegra124-soctherm";
-   reg = <0x0 0x700e2000 0x0 0x1000>;
+   compatible = "nvidia,tegra132-soctherm";
+   reg = <0x0 0x700e2000 0x0 0x600>;
interrupts = ;
clocks = <_car TEGRA124_CLK_TSENSOR>,
<_car TEGRA124_CLK_SOC_THERM>;
@@ -738,6 +739,37 @@
#thermal-sensor-cells = <1>;
};
 
+   thermal-zones {
+   cpu {
+   polling-delay-passive = <1000>;
+   polling-delay = <0>;
+
+   thermal-sensors =
+   < TEGRA124_SOCTHERM_SENSOR_CPU>;
+   };
+   mem {
+   polling-delay-passive = <0>;
+   polling-delay = <0>;
+
+   thermal-sensors =
+   < TEGRA124_SOCTHERM_SENSOR_MEM>;
+   };
+   gpu {
+   polling-delay-passive = <1000>;
+   polling-delay = <0>;
+
+   thermal-sensors =
+   < TEGRA124_SOCTHERM_SENSOR_GPU>;
+   };
+   pllx {
+   polling-delay-passive = <0>;
+   polling-delay = <0>;
+
+   thermal-sensors =
+   < TEGRA124_SOCTHERM_SENSOR_PLLX>;
+   };
+   };
+
ahub@7030 {
compatible = "nvidia,tegra124-ahub";
reg = <0x0 0x7030 0x0 0x200>,
-- 
1.9.1

[PATCH v2 6/9] thermal: tegra: add hw-throttle for Tegra132

[Wei Ni]

Tegra132 use CCROC throttle registers to configure
pulse skiper, set these registers to enable throttle
function for Tegra132.

Signed-off-by: Wei Ni 
---
 drivers/thermal/tegra/soctherm.c| 215 +---
 drivers/thermal/tegra/tegra132-soctherm.c   |  17 ++
 include/dt-bindings/thermal/tegra124-soctherm.h |   5 +
 3 files changed, 212 insertions(+), 25 deletions(-)

diff --git a/drivers/thermal/tegra/soctherm.c b/drivers/thermal/tegra/soctherm.c
index e6c4085f876d..900834637464 100644
--- a/drivers/thermal/tegra/soctherm.c
+++ b/drivers/thermal/tegra/soctherm.c
@@ -136,6 +136,21 @@
 #define CAR_SUPER_CCLKG_DIVIDER0x36c
 #define CDIVG_USE_THERM_CONTROLS_MASK  BIT(30)
 
+/* ccroc register offsets needed for enabling HW throttling for Tegra132 */
+#define CCROC_SUPER_CCLKG_DIVIDER  0x024
+
+#define CCROC_GLOBAL_CFG   0x148
+
+#define CCROC_THROT_PSKIP_RAMP_CPU 0x150
+#define CCROC_THROT_PSKIP_RAMP_SEQ_BYPASS_MODE_MASKBIT(31)
+#define CCROC_THROT_PSKIP_RAMP_DURATION_MASK   (0x << 8)
+#define CCROC_THROT_PSKIP_RAMP_STEP_MASK   0xff
+
+#define CCROC_THROT_PSKIP_CTRL_CPU 0x154
+#define CCROC_THROT_PSKIP_CTRL_ENB_MASKBIT(31)
+#define CCROC_THROT_PSKIP_CTRL_DIVIDEND_MASK   (0xff << 8)
+#define CCROC_THROT_PSKIP_CTRL_DIVISOR_MASK0xff
+
 /* get val from register(r) mask bits(m) */
 #define REG_GET_MASK(r, m) (((r) & (m)) >> (ffs(m) - 1))
 /* set val(v) to mask bits(m) of register(r) */
@@ -158,6 +173,13 @@
 #define THROT_DELAY_CTRL(throt)(THROT_DELAY_LITE + \
(THROT_OFFSET * throt))
 
+/* get CCROC_THROT_PSKIP_xxx offset per HIGH/MED/LOW vect*/
+#define CCROC_THROT_OFFSET 0x0c
+#define CCROC_THROT_PSKIP_CTRL_CPU_REG(vect)(CCROC_THROT_PSKIP_CTRL_CPU + \
+   (CCROC_THROT_OFFSET * vect))
+#define CCROC_THROT_PSKIP_RAMP_CPU_REG(vect)(CCROC_THROT_PSKIP_RAMP_CPU + \
+   (CCROC_THROT_OFFSET * vect))
+
 /* get THERMCTL_LEVELx offset per CPU/GPU/MEM/TSENSE rg and LEVEL0~3 lv */
 #define THERMCTL_LVL_REGS_SIZE 0x20
 #define THERMCTL_LVL_REG(rg, lv)   ((rg) + ((lv) * THERMCTL_LVL_REGS_SIZE))
@@ -195,6 +217,7 @@ struct soctherm_throt_cfg {
const char *name;
unsigned int id;
u8 priority;
+   u8 cpu_throt_level;
u32 cpu_throt_depth;
struct thermal_cooling_device *cdev;
bool init;
@@ -206,6 +229,7 @@ struct tegra_soctherm {
struct clk *clock_soctherm;
void __iomem *regs;
void __iomem *clk_regs;
+   void __iomem *ccroc_regs;
 
u32 *calib;
struct thermal_zone_device **thermctl_tzs;
@@ -241,6 +265,31 @@ static inline u32 clk_readl(struct tegra_soctherm *ts, u32 
reg)
return readl(ts->clk_regs + reg);
 }
 
+/**
+ * ccroc_writel() - writes a value to a CCROC register
+ * @ts: pointer to a struct tegra_soctherm
+ * @v: the value to write
+ * @reg: the register offset
+ *
+ * Writes @v to @reg.  No return value.
+ */
+static inline void ccroc_writel(struct tegra_soctherm *ts, u32 value, u32 reg)
+{
+   writel(value, (ts->ccroc_regs + reg));
+}
+
+/**
+ * ccroc_readl() - reads specified register from CCROC IP block
+ * @ts: pointer to a struct tegra_soctherm
+ * @reg: register address to be read
+ *
+ * Return: the value of the register
+ */
+static inline u32 ccroc_readl(struct tegra_soctherm *ts, u32 reg)
+{
+   return readl(ts->ccroc_regs + reg);
+}
+
 static void enable_tsensor(struct tegra_soctherm *tegra, unsigned int i)
 {
const struct tegra_tsensor *sensor = >soc->tsensors[i];
@@ -552,9 +601,6 @@ static int tegra_soctherm_set_hwtrips(struct device *dev,
 sg->name, temperature);
 
 set_throttle:
-   if (ts->soc->use_ccroc)
-   return 0;
-
ret = get_hot_temp(tz, , );
if (ret) {
dev_warn(dev, "throttle: %s: missing hot temperature\n",
@@ -676,9 +722,6 @@ static int regs_show(struct seq_file *s, void *data)
state = REG_GET_MASK(r, SENSOR_TEMP2_MEM_TEMP_MASK);
seq_printf(s, " MEM(%d)\n", translate_temp(state));
 
-   if (ts->soc->use_ccroc)
-   return 0;
-
for (i = 0; i < ts->soc->num_ttgs; i++) {
seq_printf(s, "%s:\n", ttgs[i]->name);
for (level = 0; level < 4; level++) {
@@ -779,12 +822,17 @@ static int regs_show(struct seq_file *s, void *data)
seq_printf(s, "enabled(%d)\n", state);
 
r = readl(ts->regs + CPU_PSKIP_STATUS);
-   state = REG_GET_MASK(r, XPU_PSKIP_STATUS_M_MASK);
-   seq_printf(s, "CPU PSKIP STATUS: M(%d) ", state);
-   state = REG_GET_MASK(r, XPU_PSKIP_STATUS_N_MASK);
-   seq_printf(s, "N(%d) ", state);
-   state = REG_GET_MASK(r, XPU_PSKIP_STATUS_ENABLED_MASK);
-   seq_printf(s, 

Re: [PATCH] dmaengine: pl330: Fix race in pl330_get_desc()

[Jassi Brar]

On Tue, Apr 26, 2016 at 10:00 PM, Robin Murphy  wrote:
> The current logic in pl330_get_desc() contains a clear race condition,
> whereby if the descriptor pool is empty, we will create a new
> descriptor, add it to the pool with the lock held, *release the lock*,
> then try to remove it from the pool again.
>
> Furthermore, if that second attempt then finds the pool empty because
> someone else got there first, we conclude that something must have gone
> terribly wrong and it's the absolute end of the world.
>
We may retry or simply increase the number of descriptors allocated in
a batch from 1 to, say, NR_DEFAULT_DESC.

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 372b435..7179a4d 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2449,7 +2449,7 @@ static struct dma_pl330_desc
*pl330_get_desc(struct dma_pl330_chan *pch)

/* If the DMAC pool is empty, alloc new */
if (!desc) {
-   if (!add_desc(pl330, GFP_ATOMIC, 1))
+   if (!add_desc(pl330, GFP_ATOMIC, NR_DEFAULT_DESC))
return NULL;

/* Try again */

> ...
> [  709.328891] dma-pl330 7ff0.dma: pl330_get_desc:2459 ALERT!
> ** 10 printk messages dropped ** [  709.352280] dma-pl330 7ff0.dma: 
> __pl330_prep_dma_memcpy:2493 Unable to fetch desc
> ** 11 printk messages dropped ** [  709.372930] dma-pl330 7ff0.dma: 
> pl330_get_desc:2459 ALERT!
> ** 2 printk messages dropped ** [  709.372953] dma-pl330 7ff0.dma: 
> pl330_get_desc:2459 ALERT!
> ** 8 printk messages dropped ** [  709.374157] dma-pl330 7ff0.dma: 
> __pl330_prep_dma_memcpy:2493 Unable to fetch desc
> ** 41 printk messages dropped ** [  709.393095] dmatest: dma0chan4-copy1: 
> result #4545: 'prep error' with src_off=0x3a32 dst_off=0x46dd len=0xc5c3 (0)
> ...
>
> Down with this sort of thing! The most sensible thing to do is avoid the
> allocate-add-remove dance entirely and simply use the freshly-allocated
> descriptor straight away.
>
... but you still try to first pluck from the list.
Instead of churning the code, I would suggest either check in a loop
that we have a desc OR allocate 2 or NR_DEFAULT_DESC descriptors
there. Probably we get more descriptors at the same cost of memory.

>
> I'm also seeing what looks like another occasional race under the same
> conditions where pl330_tx_submit() blows up from dma_cookie_assign()
> dereferencing a bogus tx->chan, but I think that's beyond my ability to
> figure out right now. Similarly the storm of WARNs from pl330_issue_pending()
> when using a large number of small buffers and dmatest.noverify=1. This
> one was some obvious low-hanging fruit.
>
Sorry, that part of code has changed a lot since I wrote the driver,
so more details will help me.

Thanks.

[PATCH v2 0/9] Add HW throttle for Tegra soctherm

[Wei Ni]

This series add following functions for Tegra soctherm:
1. add Tegra132 support.
2. add HW throttle function.
3. set hot trip temperatures which can trigger the HW throttle.

Main changes from V1:
1. use readl/writel instead of __raw_readl/__raw_writel.
2. rebase on the linux-next.

The v1 series is in:
https://lkml.org/lkml/2016/3/31/230

Wei Ni (9):
  thermal: tegra: add Tegra132 specific SOC_THERM driver
  arm64: tegra: use tegra132-soctherm for Tegra132
  arm64: tegra: set critical trips for Tegra132
  of: Add bindings of hw throttle for soctherm
  thermal: tegra: add hw-throttle function
  thermal: tegra: add hw-throttle for Tegra132
  arm64: tegra: set hot trips for Tegra210
  arm64: tegra: set hot trips for Tegra132
  arm: tegra: set hot trips for Tegra124

 .../bindings/thermal/nvidia,tegra124-soctherm.txt  |  89 ++-
 arch/arm/boot/dts/tegra124.dtsi|  39 +-
 arch/arm64/boot/dts/nvidia/tegra132.dtsi   | 119 ++-
 arch/arm64/boot/dts/nvidia/tegra210.dtsi   |  41 +-
 drivers/thermal/tegra/Makefile |   1 +
 drivers/thermal/tegra/soctherm.c   | 838 -
 drivers/thermal/tegra/soctherm.h   |  14 +
 drivers/thermal/tegra/tegra124-soctherm.c  |  18 +
 drivers/thermal/tegra/tegra132-soctherm.c  | 214 ++
 drivers/thermal/tegra/tegra210-soctherm.c  |  18 +
 include/dt-bindings/thermal/tegra124-soctherm.h|   5 +
 11 files changed, 1359 insertions(+), 37 deletions(-)
 create mode 100644 drivers/thermal/tegra/tegra132-soctherm.c

-- 
1.9.1

[PATCH v2 7/9] arm64: tegra: set hot trips for Tegra210

[Wei Ni]

Enable throttle function for SOC_THERM.
Set "hot" trips for cpu and gpu thermal zones, which
can trigger the SOC_THERM hardware throttle.

Signed-off-by: Wei Ni 
---
 arch/arm64/boot/dts/nvidia/tegra210.dtsi | 41 +---
 1 file changed, 32 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
index e3cca58a4c86..332771ab38e8 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
@@ -804,7 +804,9 @@
 
soctherm: thermal-sensor@0,700e2000 {
compatible = "nvidia,tegra210-soctherm";
-   reg = <0x0 0x700e2000 0x0 0x1000>;
+   reg = <0x0 0x700e2000 0x0 0x600 /* SOC_THERM reg_base */
+   0x0 0x60006000 0x0 0x400>; /* CAR reg_base */
+   reg-names = "soctherm-reg", "car-reg";
interrupts = ;
clocks = <_car TEGRA210_CLK_TSENSOR>,
<_car TEGRA210_CLK_SOC_THERM>;
@@ -812,6 +814,15 @@
resets = <_car 78>;
reset-names = "soctherm";
#thermal-sensor-cells = <1>;
+
+   throttle-cfgs {
+   throttle_heavy: heavy {
+   priority = <100>;
+   cpu-throt-depth = <85>;
+
+   #cooling-cells = <2>;
+   };
+   };
};
 
thermal-zones {
@@ -828,13 +839,19 @@
hysteresis = <0>;
type = "critical";
};
+
+   cpu_throttle_trip: throttle-trip {
+   temperature = <98500>;
+   hysteresis = <1000>;
+   type = "hot";
+   };
};
 
cooling-maps {
-   /*
-* There are currently no cooling maps,
-* because there are no cooling devices.
-*/
+   map0 {
+   trip = <_throttle_trip>;
+   cooling-device = <_heavy 1 1>;
+   };
};
};
mem {
@@ -872,13 +889,19 @@
hysteresis = <0>;
type = "critical";
};
+
+   gpu_throttle_trip: throttle-trip {
+   temperature = <10>;
+   hysteresis = <1000>;
+   type = "hot";
+   };
};
 
cooling-maps {
-   /*
-* There are currently no cooling maps,
-* because there are no cooling devices.
-*/
+   map0 {
+   trip = <_throttle_trip>;
+   cooling-device = <_heavy 1 1>;
+   };
};
};
pllx {
-- 
1.9.1

[PATCH v2 5/9] thermal: tegra: add hw-throttle function

[Wei Ni]

Tegra soctherm support HW throttle, when the soctherm snesors'
temperature is above the throttle trip point, it will trigger
pulse skiper to tune clocks accroding to the throttle depth.
Add this function for Tegra124 and Tegra210.
Since Tegra132 use different registers to configure pulse skiper,
will support it in next patch.

Signed-off-by: Wei Ni 
---
 drivers/thermal/tegra/soctherm.c  | 667 +-
 drivers/thermal/tegra/soctherm.h  |  10 +
 drivers/thermal/tegra/tegra124-soctherm.c |  18 +
 drivers/thermal/tegra/tegra132-soctherm.c |   1 +
 drivers/thermal/tegra/tegra210-soctherm.c |  18 +
 5 files changed, 699 insertions(+), 15 deletions(-)

diff --git a/drivers/thermal/tegra/soctherm.c b/drivers/thermal/tegra/soctherm.c
index b8651726201e..e6c4085f876d 100644
--- a/drivers/thermal/tegra/soctherm.c
+++ b/drivers/thermal/tegra/soctherm.c
@@ -30,6 +30,7 @@
 
 #include 
 
+#include "../thermal_core.h"
 #include "soctherm.h"
 
 #define SENSOR_CONFIG0 0
@@ -67,35 +68,179 @@
 #define READBACK_ADD_HALF  BIT(7)
 #define READBACK_NEGATEBIT(0)
 
+/*
+ * THERMCTL_LEVEL0_GROUP_CPU is defined in soctherm.h
+ * because it will be used by tegraxxx_soctherm.c
+ */
+#define THERMCTL_LVL0_CPU0_EN_MASK BIT(8)
+#define THERMCTL_LVL0_CPU0_CPU_THROT_MASK  (0x3 << 5)
+#define THERMCTL_LVL0_CPU0_CPU_THROT_LIGHT 0x1
+#define THERMCTL_LVL0_CPU0_CPU_THROT_HEAVY 0x2
+#define THERMCTL_LVL0_CPU0_GPU_THROT_MASK  (0x3 << 3)
+#define THERMCTL_LVL0_CPU0_GPU_THROT_LIGHT 0x1
+#define THERMCTL_LVL0_CPU0_GPU_THROT_HEAVY 0x2
+#define THERMCTL_LVL0_CPU0_MEM_THROT_MASK  BIT(2)
+#define THERMCTL_LVL0_CPU0_STATUS_MASK 0x3
+
+#define THERMCTL_LVL0_UP_STATS 0x10
+#define THERMCTL_LVL0_DN_STATS 0x14
+
+#define THERMCTL_STATS_CTL 0x94
+#define STATS_CTL_CLR_DN   0x8
+#define STATS_CTL_EN_DN0x4
+#define STATS_CTL_CLR_UP   0x2
+#define STATS_CTL_EN_UP0x1
+
+#define THROT_GLOBAL_CFG   0x400
+#define THROT_GLOBAL_ENB_MASK  BIT(0)
+
+#define CPU_PSKIP_STATUS   0x418
+#define XPU_PSKIP_STATUS_M_MASK(0xff << 12)
+#define XPU_PSKIP_STATUS_N_MASK(0xff << 4)
+#define XPU_PSKIP_STATUS_SW_OVERRIDE_MASK  BIT(1)
+#define XPU_PSKIP_STATUS_ENABLED_MASK  BIT(0)
+
+#define THROT_PRIORITY_LOCK0x424
+#define THROT_PRIORITY_LOCK_PRIORITY_MASK  0xff
+
+#define THROT_STATUS   0x428
+#define THROT_STATUS_BREACH_MASK   BIT(12)
+#define THROT_STATUS_STATE_MASK(0xff << 4)
+#define THROT_STATUS_ENABLED_MASK  BIT(0)
+
+#define THROT_PSKIP_CTRL_LITE_CPU  0x430
+#define THROT_PSKIP_CTRL_ENABLE_MASKBIT(31)
+#define THROT_PSKIP_CTRL_DIVIDEND_MASK  (0xff << 8)
+#define THROT_PSKIP_CTRL_DIVISOR_MASK   0xff
+#define THROT_PSKIP_CTRL_VECT_GPU_MASK  (0x7 << 16)
+#define THROT_PSKIP_CTRL_VECT_CPU_MASK  (0x7 << 8)
+#define THROT_PSKIP_CTRL_VECT2_CPU_MASK 0x7
+
+#define THROT_VECT_NONE0x0 /* 3'b000 */
+#define THROT_VECT_LOW 0x1 /* 3'b001 */
+#define THROT_VECT_MED 0x3 /* 3'b011 */
+#define THROT_VECT_HIGH0x7 /* 3'b111 */
+
+#define THROT_PSKIP_RAMP_LITE_CPU  0x434
+#define THROT_PSKIP_RAMP_SEQ_BYPASS_MODE_MASK  BIT(31)
+#define THROT_PSKIP_RAMP_DURATION_MASK (0x << 8)
+#define THROT_PSKIP_RAMP_STEP_MASK 0xff
+
+#define THROT_PRIORITY_LITE0x444
+#define THROT_PRIORITY_LITE_PRIO_MASK  0xff
+
+#define THROT_DELAY_LITE   0x448
+#define THROT_DELAY_LITE_DELAY_MASK0xff
+
+/* car register offsets needed for enabling HW throttling */
+#define CAR_SUPER_CCLKG_DIVIDER0x36c
+#define CDIVG_USE_THERM_CONTROLS_MASK  BIT(30)
+
 /* get val from register(r) mask bits(m) */
 #define REG_GET_MASK(r, m) (((r) & (m)) >> (ffs(m) - 1))
 /* set val(v) to mask bits(m) of register(r) */
 #define REG_SET_MASK(r, m, v)  (((r) & ~(m)) | \
 (((v) & (m >> (ffs(m) - 1))) << (ffs(m) - 1)))
 
+/* get dividend from the depth */
+#define THROT_DEPTH_DIVIDEND(depth)((256 * (100 - (depth)) / 100) - 1)
+
+/* get THROT_PSKIP_xxx offset per LIGHT/HEAVY throt and CPU/GPU dev */
+#define THROT_OFFSET   0x30
+#define THROT_PSKIP_CTRL(throt, dev)   (THROT_PSKIP_CTRL_LITE_CPU + \
+   (THROT_OFFSET * throt) + (8 * dev))
+#define THROT_PSKIP_RAMP(throt, dev)   (THROT_PSKIP_RAMP_LITE_CPU + \
+

Re: [PATCH] dmaengine: pl330: Fix race in pl330_get_desc()

[Jassi Brar]

On Tue, Apr 26, 2016 at 10:00 PM, Robin Murphy  wrote:
> The current logic in pl330_get_desc() contains a clear race condition,
> whereby if the descriptor pool is empty, we will create a new
> descriptor, add it to the pool with the lock held, *release the lock*,
> then try to remove it from the pool again.
>
> Furthermore, if that second attempt then finds the pool empty because
> someone else got there first, we conclude that something must have gone
> terribly wrong and it's the absolute end of the world.
>
We may retry or simply increase the number of descriptors allocated in
a batch from 1 to, say, NR_DEFAULT_DESC.

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 372b435..7179a4d 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2449,7 +2449,7 @@ static struct dma_pl330_desc
*pl330_get_desc(struct dma_pl330_chan *pch)

/* If the DMAC pool is empty, alloc new */
if (!desc) {
-   if (!add_desc(pl330, GFP_ATOMIC, 1))
+   if (!add_desc(pl330, GFP_ATOMIC, NR_DEFAULT_DESC))
return NULL;

/* Try again */

> ...
> [  709.328891] dma-pl330 7ff0.dma: pl330_get_desc:2459 ALERT!
> ** 10 printk messages dropped ** [  709.352280] dma-pl330 7ff0.dma: 
> __pl330_prep_dma_memcpy:2493 Unable to fetch desc
> ** 11 printk messages dropped ** [  709.372930] dma-pl330 7ff0.dma: 
> pl330_get_desc:2459 ALERT!
> ** 2 printk messages dropped ** [  709.372953] dma-pl330 7ff0.dma: 
> pl330_get_desc:2459 ALERT!
> ** 8 printk messages dropped ** [  709.374157] dma-pl330 7ff0.dma: 
> __pl330_prep_dma_memcpy:2493 Unable to fetch desc
> ** 41 printk messages dropped ** [  709.393095] dmatest: dma0chan4-copy1: 
> result #4545: 'prep error' with src_off=0x3a32 dst_off=0x46dd len=0xc5c3 (0)
> ...
>
> Down with this sort of thing! The most sensible thing to do is avoid the
> allocate-add-remove dance entirely and simply use the freshly-allocated
> descriptor straight away.
>
... but you still try to first pluck from the list.
Instead of churning the code, I would suggest either check in a loop
that we have a desc OR allocate 2 or NR_DEFAULT_DESC descriptors
there. Probably we get more descriptors at the same cost of memory.

>
> I'm also seeing what looks like another occasional race under the same
> conditions where pl330_tx_submit() blows up from dma_cookie_assign()
> dereferencing a bogus tx->chan, but I think that's beyond my ability to
> figure out right now. Similarly the storm of WARNs from pl330_issue_pending()
> when using a large number of small buffers and dmatest.noverify=1. This
> one was some obvious low-hanging fruit.
>
Sorry, that part of code has changed a lot since I wrote the driver,
so more details will help me.

Thanks.

[PATCH v2 0/9] Add HW throttle for Tegra soctherm

[Wei Ni]

This series add following functions for Tegra soctherm:
1. add Tegra132 support.
2. add HW throttle function.
3. set hot trip temperatures which can trigger the HW throttle.

Main changes from V1:
1. use readl/writel instead of __raw_readl/__raw_writel.
2. rebase on the linux-next.

The v1 series is in:
https://lkml.org/lkml/2016/3/31/230

Wei Ni (9):
  thermal: tegra: add Tegra132 specific SOC_THERM driver
  arm64: tegra: use tegra132-soctherm for Tegra132
  arm64: tegra: set critical trips for Tegra132
  of: Add bindings of hw throttle for soctherm
  thermal: tegra: add hw-throttle function
  thermal: tegra: add hw-throttle for Tegra132
  arm64: tegra: set hot trips for Tegra210
  arm64: tegra: set hot trips for Tegra132
  arm: tegra: set hot trips for Tegra124

 .../bindings/thermal/nvidia,tegra124-soctherm.txt  |  89 ++-
 arch/arm/boot/dts/tegra124.dtsi|  39 +-
 arch/arm64/boot/dts/nvidia/tegra132.dtsi   | 119 ++-
 arch/arm64/boot/dts/nvidia/tegra210.dtsi   |  41 +-
 drivers/thermal/tegra/Makefile |   1 +
 drivers/thermal/tegra/soctherm.c   | 838 -
 drivers/thermal/tegra/soctherm.h   |  14 +
 drivers/thermal/tegra/tegra124-soctherm.c  |  18 +
 drivers/thermal/tegra/tegra132-soctherm.c  | 214 ++
 drivers/thermal/tegra/tegra210-soctherm.c  |  18 +
 include/dt-bindings/thermal/tegra124-soctherm.h|   5 +
 11 files changed, 1359 insertions(+), 37 deletions(-)
 create mode 100644 drivers/thermal/tegra/tegra132-soctherm.c

-- 
1.9.1

[PATCH v2 7/9] arm64: tegra: set hot trips for Tegra210

[Wei Ni]

Enable throttle function for SOC_THERM.
Set "hot" trips for cpu and gpu thermal zones, which
can trigger the SOC_THERM hardware throttle.

Signed-off-by: Wei Ni 
---
 arch/arm64/boot/dts/nvidia/tegra210.dtsi | 41 +---
 1 file changed, 32 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
index e3cca58a4c86..332771ab38e8 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
@@ -804,7 +804,9 @@
 
soctherm: thermal-sensor@0,700e2000 {
compatible = "nvidia,tegra210-soctherm";
-   reg = <0x0 0x700e2000 0x0 0x1000>;
+   reg = <0x0 0x700e2000 0x0 0x600 /* SOC_THERM reg_base */
+   0x0 0x60006000 0x0 0x400>; /* CAR reg_base */
+   reg-names = "soctherm-reg", "car-reg";
interrupts = ;
clocks = <_car TEGRA210_CLK_TSENSOR>,
<_car TEGRA210_CLK_SOC_THERM>;
@@ -812,6 +814,15 @@
resets = <_car 78>;
reset-names = "soctherm";
#thermal-sensor-cells = <1>;
+
+   throttle-cfgs {
+   throttle_heavy: heavy {
+   priority = <100>;
+   cpu-throt-depth = <85>;
+
+   #cooling-cells = <2>;
+   };
+   };
};
 
thermal-zones {
@@ -828,13 +839,19 @@
hysteresis = <0>;
type = "critical";
};
+
+   cpu_throttle_trip: throttle-trip {
+   temperature = <98500>;
+   hysteresis = <1000>;
+   type = "hot";
+   };
};
 
cooling-maps {
-   /*
-* There are currently no cooling maps,
-* because there are no cooling devices.
-*/
+   map0 {
+   trip = <_throttle_trip>;
+   cooling-device = <_heavy 1 1>;
+   };
};
};
mem {
@@ -872,13 +889,19 @@
hysteresis = <0>;
type = "critical";
};
+
+   gpu_throttle_trip: throttle-trip {
+   temperature = <10>;
+   hysteresis = <1000>;
+   type = "hot";
+   };
};
 
cooling-maps {
-   /*
-* There are currently no cooling maps,
-* because there are no cooling devices.
-*/
+   map0 {
+   trip = <_throttle_trip>;
+   cooling-device = <_heavy 1 1>;
+   };
};
};
pllx {
-- 
1.9.1

[PATCH v2 5/9] thermal: tegra: add hw-throttle function

[Wei Ni]

Tegra soctherm support HW throttle, when the soctherm snesors'
temperature is above the throttle trip point, it will trigger
pulse skiper to tune clocks accroding to the throttle depth.
Add this function for Tegra124 and Tegra210.
Since Tegra132 use different registers to configure pulse skiper,
will support it in next patch.

Signed-off-by: Wei Ni 
---
 drivers/thermal/tegra/soctherm.c  | 667 +-
 drivers/thermal/tegra/soctherm.h  |  10 +
 drivers/thermal/tegra/tegra124-soctherm.c |  18 +
 drivers/thermal/tegra/tegra132-soctherm.c |   1 +
 drivers/thermal/tegra/tegra210-soctherm.c |  18 +
 5 files changed, 699 insertions(+), 15 deletions(-)

diff --git a/drivers/thermal/tegra/soctherm.c b/drivers/thermal/tegra/soctherm.c
index b8651726201e..e6c4085f876d 100644
--- a/drivers/thermal/tegra/soctherm.c
+++ b/drivers/thermal/tegra/soctherm.c
@@ -30,6 +30,7 @@
 
 #include 
 
+#include "../thermal_core.h"
 #include "soctherm.h"
 
 #define SENSOR_CONFIG0 0
@@ -67,35 +68,179 @@
 #define READBACK_ADD_HALF  BIT(7)
 #define READBACK_NEGATEBIT(0)
 
+/*
+ * THERMCTL_LEVEL0_GROUP_CPU is defined in soctherm.h
+ * because it will be used by tegraxxx_soctherm.c
+ */
+#define THERMCTL_LVL0_CPU0_EN_MASK BIT(8)
+#define THERMCTL_LVL0_CPU0_CPU_THROT_MASK  (0x3 << 5)
+#define THERMCTL_LVL0_CPU0_CPU_THROT_LIGHT 0x1
+#define THERMCTL_LVL0_CPU0_CPU_THROT_HEAVY 0x2
+#define THERMCTL_LVL0_CPU0_GPU_THROT_MASK  (0x3 << 3)
+#define THERMCTL_LVL0_CPU0_GPU_THROT_LIGHT 0x1
+#define THERMCTL_LVL0_CPU0_GPU_THROT_HEAVY 0x2
+#define THERMCTL_LVL0_CPU0_MEM_THROT_MASK  BIT(2)
+#define THERMCTL_LVL0_CPU0_STATUS_MASK 0x3
+
+#define THERMCTL_LVL0_UP_STATS 0x10
+#define THERMCTL_LVL0_DN_STATS 0x14
+
+#define THERMCTL_STATS_CTL 0x94
+#define STATS_CTL_CLR_DN   0x8
+#define STATS_CTL_EN_DN0x4
+#define STATS_CTL_CLR_UP   0x2
+#define STATS_CTL_EN_UP0x1
+
+#define THROT_GLOBAL_CFG   0x400
+#define THROT_GLOBAL_ENB_MASK  BIT(0)
+
+#define CPU_PSKIP_STATUS   0x418
+#define XPU_PSKIP_STATUS_M_MASK(0xff << 12)
+#define XPU_PSKIP_STATUS_N_MASK(0xff << 4)
+#define XPU_PSKIP_STATUS_SW_OVERRIDE_MASK  BIT(1)
+#define XPU_PSKIP_STATUS_ENABLED_MASK  BIT(0)
+
+#define THROT_PRIORITY_LOCK0x424
+#define THROT_PRIORITY_LOCK_PRIORITY_MASK  0xff
+
+#define THROT_STATUS   0x428
+#define THROT_STATUS_BREACH_MASK   BIT(12)
+#define THROT_STATUS_STATE_MASK(0xff << 4)
+#define THROT_STATUS_ENABLED_MASK  BIT(0)
+
+#define THROT_PSKIP_CTRL_LITE_CPU  0x430
+#define THROT_PSKIP_CTRL_ENABLE_MASKBIT(31)
+#define THROT_PSKIP_CTRL_DIVIDEND_MASK  (0xff << 8)
+#define THROT_PSKIP_CTRL_DIVISOR_MASK   0xff
+#define THROT_PSKIP_CTRL_VECT_GPU_MASK  (0x7 << 16)
+#define THROT_PSKIP_CTRL_VECT_CPU_MASK  (0x7 << 8)
+#define THROT_PSKIP_CTRL_VECT2_CPU_MASK 0x7
+
+#define THROT_VECT_NONE0x0 /* 3'b000 */
+#define THROT_VECT_LOW 0x1 /* 3'b001 */
+#define THROT_VECT_MED 0x3 /* 3'b011 */
+#define THROT_VECT_HIGH0x7 /* 3'b111 */
+
+#define THROT_PSKIP_RAMP_LITE_CPU  0x434
+#define THROT_PSKIP_RAMP_SEQ_BYPASS_MODE_MASK  BIT(31)
+#define THROT_PSKIP_RAMP_DURATION_MASK (0x << 8)
+#define THROT_PSKIP_RAMP_STEP_MASK 0xff
+
+#define THROT_PRIORITY_LITE0x444
+#define THROT_PRIORITY_LITE_PRIO_MASK  0xff
+
+#define THROT_DELAY_LITE   0x448
+#define THROT_DELAY_LITE_DELAY_MASK0xff
+
+/* car register offsets needed for enabling HW throttling */
+#define CAR_SUPER_CCLKG_DIVIDER0x36c
+#define CDIVG_USE_THERM_CONTROLS_MASK  BIT(30)
+
 /* get val from register(r) mask bits(m) */
 #define REG_GET_MASK(r, m) (((r) & (m)) >> (ffs(m) - 1))
 /* set val(v) to mask bits(m) of register(r) */
 #define REG_SET_MASK(r, m, v)  (((r) & ~(m)) | \
 (((v) & (m >> (ffs(m) - 1))) << (ffs(m) - 1)))
 
+/* get dividend from the depth */
+#define THROT_DEPTH_DIVIDEND(depth)((256 * (100 - (depth)) / 100) - 1)
+
+/* get THROT_PSKIP_xxx offset per LIGHT/HEAVY throt and CPU/GPU dev */
+#define THROT_OFFSET   0x30
+#define THROT_PSKIP_CTRL(throt, dev)   (THROT_PSKIP_CTRL_LITE_CPU + \
+   (THROT_OFFSET * throt) + (8 * dev))
+#define THROT_PSKIP_RAMP(throt, dev)   (THROT_PSKIP_RAMP_LITE_CPU + \
+ 

[PATCH v2 1/9] thermal: tegra: add Tegra132 specific SOC_THERM driver

[Wei Ni]

add Tegra132 specific SOC_THERM driver.

Signed-off-by: Wei Ni 
---
 drivers/thermal/tegra/Makefile|   1 +
 drivers/thermal/tegra/soctherm.c  |   6 +
 drivers/thermal/tegra/soctherm.h  |   4 +
 drivers/thermal/tegra/tegra132-soctherm.c | 196 ++
 4 files changed, 207 insertions(+)
 create mode 100644 drivers/thermal/tegra/tegra132-soctherm.c

diff --git a/drivers/thermal/tegra/Makefile b/drivers/thermal/tegra/Makefile
index bf9e028eba28..1ce1af2cf0f5 100644
--- a/drivers/thermal/tegra/Makefile
+++ b/drivers/thermal/tegra/Makefile
@@ -2,4 +2,5 @@ obj-$(CONFIG_TEGRA_SOCTHERM)+= tegra-soctherm.o
 
 tegra-soctherm-y   := soctherm.o soctherm-fuse.o
 tegra-soctherm-$(CONFIG_ARCH_TEGRA_124_SOC)+= tegra124-soctherm.o
+tegra-soctherm-$(CONFIG_ARCH_TEGRA_132_SOC)+= tegra132-soctherm.o
 tegra-soctherm-$(CONFIG_ARCH_TEGRA_210_SOC)+= tegra210-soctherm.o
diff --git a/drivers/thermal/tegra/soctherm.c b/drivers/thermal/tegra/soctherm.c
index 2b0417d7b754..b8651726201e 100644
--- a/drivers/thermal/tegra/soctherm.c
+++ b/drivers/thermal/tegra/soctherm.c
@@ -484,6 +484,12 @@ static const struct of_device_id tegra_soctherm_of_match[] 
= {
.data = _soctherm,
},
 #endif
+#ifdef CONFIG_ARCH_TEGRA_132_SOC
+   {
+   .compatible = "nvidia,tegra132-soctherm",
+   .data = _soctherm,
+   },
+#endif
 #ifdef CONFIG_ARCH_TEGRA_210_SOC
{
.compatible = "nvidia,tegra210-soctherm",
diff --git a/drivers/thermal/tegra/soctherm.h b/drivers/thermal/tegra/soctherm.h
index f6dbbba80367..28e18ec4b4c3 100644
--- a/drivers/thermal/tegra/soctherm.h
+++ b/drivers/thermal/tegra/soctherm.h
@@ -115,6 +115,10 @@ int tegra_calc_tsensor_calib(const struct tegra_tsensor 
*sensor,
 extern const struct tegra_soctherm_soc tegra124_soctherm;
 #endif
 
+#ifdef CONFIG_ARCH_TEGRA_132_SOC
+extern const struct tegra_soctherm_soc tegra132_soctherm;
+#endif
+
 #ifdef CONFIG_ARCH_TEGRA_210_SOC
 extern const struct tegra_soctherm_soc tegra210_soctherm;
 #endif
diff --git a/drivers/thermal/tegra/tegra132-soctherm.c 
b/drivers/thermal/tegra/tegra132-soctherm.c
new file mode 100644
index ..e2aa84e1b307
--- /dev/null
+++ b/drivers/thermal/tegra/tegra132-soctherm.c
@@ -0,0 +1,196 @@
+/*
+ * Copyright (c) 2014-2016, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+
+#include 
+
+#include "soctherm.h"
+
+#define TEGRA132_THERMTRIP_ANY_EN_MASK (0x1 << 28)
+#define TEGRA132_THERMTRIP_MEM_EN_MASK (0x1 << 27)
+#define TEGRA132_THERMTRIP_GPU_EN_MASK (0x1 << 26)
+#define TEGRA132_THERMTRIP_CPU_EN_MASK (0x1 << 25)
+#define TEGRA132_THERMTRIP_TSENSE_EN_MASK  (0x1 << 24)
+#define TEGRA132_THERMTRIP_GPUMEM_THRESH_MASK  (0xff << 16)
+#define TEGRA132_THERMTRIP_CPU_THRESH_MASK (0xff << 8)
+#define TEGRA132_THERMTRIP_TSENSE_THRESH_MASK  0xff
+
+#define TEGRA132_THRESH_GRAIN  1000
+
+static const struct tegra_tsensor_configuration tegra132_tsensor_config = {
+   .tall = 16300,
+   .tiddq_en = 1,
+   .ten_count = 1,
+   .tsample = 120,
+   .tsample_ate = 480,
+};
+
+static const struct tegra_tsensor_group tegra132_tsensor_group_cpu = {
+   .id = TEGRA124_SOCTHERM_SENSOR_CPU,
+   .name = "cpu",
+   .sensor_temp_offset = SENSOR_TEMP1,
+   .sensor_temp_mask = SENSOR_TEMP1_CPU_TEMP_MASK,
+   .pdiv = 8,
+   .pdiv_ate = 8,
+   .pdiv_mask = SENSOR_PDIV_CPU_MASK,
+   .pllx_hotspot_diff = 10,
+   .pllx_hotspot_mask = SENSOR_HOTSPOT_CPU_MASK,
+   .thermtrip_any_en_mask = TEGRA132_THERMTRIP_ANY_EN_MASK,
+   .thermtrip_enable_mask = TEGRA132_THERMTRIP_CPU_EN_MASK,
+   .thermtrip_threshold_mask = TEGRA132_THERMTRIP_CPU_THRESH_MASK,
+};
+
+static const struct tegra_tsensor_group tegra132_tsensor_group_gpu = {
+   .id = TEGRA124_SOCTHERM_SENSOR_GPU,
+   .name = "gpu",
+   .sensor_temp_offset = SENSOR_TEMP1,
+   .sensor_temp_mask = SENSOR_TEMP1_GPU_TEMP_MASK,
+   .pdiv = 8,
+   .pdiv_ate = 8,
+   .pdiv_mask = SENSOR_PDIV_GPU_MASK,
+   .pllx_hotspot_diff = 5,
+   .pllx_hotspot_mask = SENSOR_HOTSPOT_GPU_MASK,
+   .thermtrip_any_en_mask = TEGRA132_THERMTRIP_ANY_EN_MASK,
+   .thermtrip_enable_mask = TEGRA132_THERMTRIP_GPU_EN_MASK,
+   .thermtrip_threshold_mask = TEGRA132_THERMTRIP_GPUMEM_THRESH_MASK,
+};
+
+static const struct tegra_tsensor_group 

[PATCH v2 9/9] arm: tegra: set hot trips for Tegra124

[Wei Ni]

Enable throttle function for SOC_THERM.
Set "hot" trips for cpu and gpu thermal zones, which
can trigger the SOC_THERM hardware throttle.

Signed-off-by: Wei Ni 
---
 arch/arm/boot/dts/tegra124.dtsi | 39 ++-
 1 file changed, 30 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index 08c7f85ea2c8..c5dcb97e7bc4 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -846,7 +846,9 @@
 
soctherm: thermal-sensor@0,700e2000 {
compatible = "nvidia,tegra124-soctherm";
-   reg = <0x0 0x700e2000 0x0 0x1000>;
+   reg = <0x0 0x700e2000 0x0 0x600 /* SOC_THERM reg_base */
+   0x0 0x60006000 0x0 0x400>; /* CAR reg_base */
+   reg-names = "soctherm-reg", "car-reg";
interrupts = ;
clocks = <_car TEGRA124_CLK_TSENSOR>,
<_car TEGRA124_CLK_SOC_THERM>;
@@ -854,6 +856,15 @@
resets = <_car 78>;
reset-names = "soctherm";
#thermal-sensor-cells = <1>;
+
+   throttle-cfgs {
+   throttle_heavy: heavy {
+   priority = <100>;
+   cpu-throt-depth = <85>;
+
+   #cooling-cells = <1>;
+   };
+   };
};
 
dfll: clock@0,7011 {
@@ -1156,13 +1167,18 @@
hysteresis = <0>;
type = "critical";
};
+   cpu_throttle_trip: throttle-trip {
+   temperature = <10>;
+   hysteresis = <1000>;
+   type = "hot";
+   };
};
 
cooling-maps {
-   /*
-* There are currently no cooling maps,
-* because there are no cooling devices.
-*/
+   map0 {
+   trip = <_throttle_trip>;
+   cooling-device = <_heavy 1 1>;
+   };
};
};
 
@@ -1202,13 +1218,18 @@
hysteresis = <0>;
type = "critical";
};
+   gpu_throttle_trip: throttle-trip {
+   temperature = <99000>;
+   hysteresis = <1000>;
+   type = "hot";
+   };
};
 
cooling-maps {
-   /*
-* There are currently no cooling maps,
-* because there are no cooling devices.
-*/
+   map0 {
+   trip = <_throttle_trip>;
+   cooling-device = <_heavy 1 1>;
+   };
};
};
 
-- 
1.9.1

[PATCH v2 3/9] arm64: tegra: set critical trips for Tegra132

[Wei Ni]

Set general "critical" trip temperatures for cpu, gpu, mem and pllx
thermal zones on Tegra132, these trips can trigger shut down or reset.

Signed-off-by: Wei Ni 
---
 arch/arm64/boot/dts/nvidia/tegra132.dtsi | 60 
 1 file changed, 60 insertions(+)

diff --git a/arch/arm64/boot/dts/nvidia/tegra132.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra132.dtsi
index e41d8e82d7ed..a3889e930010 100644
--- a/arch/arm64/boot/dts/nvidia/tegra132.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra132.dtsi
@@ -746,6 +746,21 @@
 
thermal-sensors =
< TEGRA124_SOCTHERM_SENSOR_CPU>;
+
+   trips {
+   cpu_shutdown_trip {
+   temperature = <105000>;
+   hysteresis = <1000>;
+   type = "critical";
+   };
+   };
+
+   cooling-maps {
+   /*
+* There are currently no cooling maps,
+* because there are no cooling devices.
+*/
+   };
};
mem {
polling-delay-passive = <0>;
@@ -753,6 +768,21 @@
 
thermal-sensors =
< TEGRA124_SOCTHERM_SENSOR_MEM>;
+
+   trips {
+   mem_shutdown_trip {
+   temperature = <101000>;
+   hysteresis = <1000>;
+   type = "critical";
+   };
+   };
+
+   cooling-maps {
+   /*
+* There are currently no cooling maps,
+* because there are no cooling devices.
+*/
+   };
};
gpu {
polling-delay-passive = <1000>;
@@ -760,6 +790,21 @@
 
thermal-sensors =
< TEGRA124_SOCTHERM_SENSOR_GPU>;
+
+   trips {
+   gpu_shutdown_trip {
+   temperature = <101000>;
+   hysteresis = <1000>;
+   type = "critical";
+   };
+   };
+
+   cooling-maps {
+   /*
+* There are currently no cooling maps,
+* because there are no cooling devices.
+*/
+   };
};
pllx {
polling-delay-passive = <0>;
@@ -767,6 +812,21 @@
 
thermal-sensors =
< TEGRA124_SOCTHERM_SENSOR_PLLX>;
+
+   trips {
+   pllx_shutdown_trip {
+   temperature = <105000>;
+   hysteresis = <1000>;
+   type = "critical";
+   };
+   };
+
+   cooling-maps {
+   /*
+* There are currently no cooling maps,
+* because there are no cooling devices.
+*/
+   };
};
};
 
-- 
1.9.1

[PATCH v2 1/9] thermal: tegra: add Tegra132 specific SOC_THERM driver

[Wei Ni]

add Tegra132 specific SOC_THERM driver.

Signed-off-by: Wei Ni 
---
 drivers/thermal/tegra/Makefile|   1 +
 drivers/thermal/tegra/soctherm.c  |   6 +
 drivers/thermal/tegra/soctherm.h  |   4 +
 drivers/thermal/tegra/tegra132-soctherm.c | 196 ++
 4 files changed, 207 insertions(+)
 create mode 100644 drivers/thermal/tegra/tegra132-soctherm.c

diff --git a/drivers/thermal/tegra/Makefile b/drivers/thermal/tegra/Makefile
index bf9e028eba28..1ce1af2cf0f5 100644
--- a/drivers/thermal/tegra/Makefile
+++ b/drivers/thermal/tegra/Makefile
@@ -2,4 +2,5 @@ obj-$(CONFIG_TEGRA_SOCTHERM)+= tegra-soctherm.o
 
 tegra-soctherm-y   := soctherm.o soctherm-fuse.o
 tegra-soctherm-$(CONFIG_ARCH_TEGRA_124_SOC)+= tegra124-soctherm.o
+tegra-soctherm-$(CONFIG_ARCH_TEGRA_132_SOC)+= tegra132-soctherm.o
 tegra-soctherm-$(CONFIG_ARCH_TEGRA_210_SOC)+= tegra210-soctherm.o
diff --git a/drivers/thermal/tegra/soctherm.c b/drivers/thermal/tegra/soctherm.c
index 2b0417d7b754..b8651726201e 100644
--- a/drivers/thermal/tegra/soctherm.c
+++ b/drivers/thermal/tegra/soctherm.c
@@ -484,6 +484,12 @@ static const struct of_device_id tegra_soctherm_of_match[] 
= {
.data = _soctherm,
},
 #endif
+#ifdef CONFIG_ARCH_TEGRA_132_SOC
+   {
+   .compatible = "nvidia,tegra132-soctherm",
+   .data = _soctherm,
+   },
+#endif
 #ifdef CONFIG_ARCH_TEGRA_210_SOC
{
.compatible = "nvidia,tegra210-soctherm",
diff --git a/drivers/thermal/tegra/soctherm.h b/drivers/thermal/tegra/soctherm.h
index f6dbbba80367..28e18ec4b4c3 100644
--- a/drivers/thermal/tegra/soctherm.h
+++ b/drivers/thermal/tegra/soctherm.h
@@ -115,6 +115,10 @@ int tegra_calc_tsensor_calib(const struct tegra_tsensor 
*sensor,
 extern const struct tegra_soctherm_soc tegra124_soctherm;
 #endif
 
+#ifdef CONFIG_ARCH_TEGRA_132_SOC
+extern const struct tegra_soctherm_soc tegra132_soctherm;
+#endif
+
 #ifdef CONFIG_ARCH_TEGRA_210_SOC
 extern const struct tegra_soctherm_soc tegra210_soctherm;
 #endif
diff --git a/drivers/thermal/tegra/tegra132-soctherm.c 
b/drivers/thermal/tegra/tegra132-soctherm.c
new file mode 100644
index ..e2aa84e1b307
--- /dev/null
+++ b/drivers/thermal/tegra/tegra132-soctherm.c
@@ -0,0 +1,196 @@
+/*
+ * Copyright (c) 2014-2016, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+
+#include 
+
+#include "soctherm.h"
+
+#define TEGRA132_THERMTRIP_ANY_EN_MASK (0x1 << 28)
+#define TEGRA132_THERMTRIP_MEM_EN_MASK (0x1 << 27)
+#define TEGRA132_THERMTRIP_GPU_EN_MASK (0x1 << 26)
+#define TEGRA132_THERMTRIP_CPU_EN_MASK (0x1 << 25)
+#define TEGRA132_THERMTRIP_TSENSE_EN_MASK  (0x1 << 24)
+#define TEGRA132_THERMTRIP_GPUMEM_THRESH_MASK  (0xff << 16)
+#define TEGRA132_THERMTRIP_CPU_THRESH_MASK (0xff << 8)
+#define TEGRA132_THERMTRIP_TSENSE_THRESH_MASK  0xff
+
+#define TEGRA132_THRESH_GRAIN  1000
+
+static const struct tegra_tsensor_configuration tegra132_tsensor_config = {
+   .tall = 16300,
+   .tiddq_en = 1,
+   .ten_count = 1,
+   .tsample = 120,
+   .tsample_ate = 480,
+};
+
+static const struct tegra_tsensor_group tegra132_tsensor_group_cpu = {
+   .id = TEGRA124_SOCTHERM_SENSOR_CPU,
+   .name = "cpu",
+   .sensor_temp_offset = SENSOR_TEMP1,
+   .sensor_temp_mask = SENSOR_TEMP1_CPU_TEMP_MASK,
+   .pdiv = 8,
+   .pdiv_ate = 8,
+   .pdiv_mask = SENSOR_PDIV_CPU_MASK,
+   .pllx_hotspot_diff = 10,
+   .pllx_hotspot_mask = SENSOR_HOTSPOT_CPU_MASK,
+   .thermtrip_any_en_mask = TEGRA132_THERMTRIP_ANY_EN_MASK,
+   .thermtrip_enable_mask = TEGRA132_THERMTRIP_CPU_EN_MASK,
+   .thermtrip_threshold_mask = TEGRA132_THERMTRIP_CPU_THRESH_MASK,
+};
+
+static const struct tegra_tsensor_group tegra132_tsensor_group_gpu = {
+   .id = TEGRA124_SOCTHERM_SENSOR_GPU,
+   .name = "gpu",
+   .sensor_temp_offset = SENSOR_TEMP1,
+   .sensor_temp_mask = SENSOR_TEMP1_GPU_TEMP_MASK,
+   .pdiv = 8,
+   .pdiv_ate = 8,
+   .pdiv_mask = SENSOR_PDIV_GPU_MASK,
+   .pllx_hotspot_diff = 5,
+   .pllx_hotspot_mask = SENSOR_HOTSPOT_GPU_MASK,
+   .thermtrip_any_en_mask = TEGRA132_THERMTRIP_ANY_EN_MASK,
+   .thermtrip_enable_mask = TEGRA132_THERMTRIP_GPU_EN_MASK,
+   .thermtrip_threshold_mask = TEGRA132_THERMTRIP_GPUMEM_THRESH_MASK,
+};
+
+static const struct tegra_tsensor_group