I need your assistance to invest!!!

2016-12-12 Thread Miss Margaret Carnegie
Dear Sir,

I need your support to relocate and invest in your country. I ask your 
assistance because I don’t have knowledge about 
business and the rules that guide your country for safe investment.
Will you promise to be sincere with me?

Please contact me for more information details!

With best regards,
Miss Margaret Carnegie.


Re: [PATCH] orinoco: Use shash instead of ahash for MIC calculations

2016-12-12 Thread Eric Biggers
On Mon, Dec 12, 2016 at 12:55:55PM -0800, Andy Lutomirski wrote:
> +int orinoco_mic(struct crypto_shash *tfm_michael, u8 *key,
>   u8 *da, u8 *sa, u8 priority,
>   u8 *data, size_t data_len, u8 *mic)
>  {
> - AHASH_REQUEST_ON_STACK(req, tfm_michael);
> - struct scatterlist sg[2];
> + SHASH_DESC_ON_STACK(desc, tfm_michael);
>   u8 hdr[ETH_HLEN + 2]; /* size of header + padding */
>   int err;
>  
> @@ -67,18 +66,27 @@ int orinoco_mic(struct crypto_ahash *tfm_michael, u8 *key,
>   hdr[ETH_ALEN * 2 + 2] = 0;
>   hdr[ETH_ALEN * 2 + 3] = 0;
>  
> - /* Use scatter gather to MIC header and data in one go */
> - sg_init_table(sg, 2);
> - sg_set_buf([0], hdr, sizeof(hdr));
> - sg_set_buf([1], data, data_len);
> + desc->tfm = tfm_michael;
> + desc->flags = 0;
>  
> - if (crypto_ahash_setkey(tfm_michael, key, MIC_KEYLEN))
> - return -1;
> + err = crypto_shash_setkey(tfm_michael, key, MIC_KEYLEN);
> + if (err)
> + return err;
> +
> + err = crypto_shash_init(desc);
> + if (err)
> + return err;
> +
> + err = crypto_shash_update(desc, hdr, sizeof(hdr));
> + if (err)
> + return err;
> +
> + err = crypto_shash_update(desc, data, data_len);
> + if (err)
> + return err;
> +
> + err = crypto_shash_final(desc, mic);
> + shash_desc_zero(desc);
>  
> - ahash_request_set_tfm(req, tfm_michael);
> - ahash_request_set_callback(req, 0, NULL, NULL);
> - ahash_request_set_crypt(req, sg, mic, data_len + sizeof(hdr));
> - err = crypto_ahash_digest(req);
> - ahash_request_zero(req);
>   return err;

It's probably a good idea to always do shash_desc_zero(), even when something
above it fails.  Otherwise this looks fine.  Thanks for sending these patches!

Eric


Re: [PATCH v5 2/2] mmc: sdhci-cadence: add Cadence SD4HC support

2016-12-12 Thread Ulf Hansson
[...]

>>> +
>>> +Optional properties:
>>> +For eMMC configuration, supported speed modes are not indicated by the 
>>> SDHCI
>>> +Capabilities Register.  Instead, the following properties should be 
>>> specified
>>> +if supported.  See mmc.txt for details.
>>> +- mmc-ddr-1_8v
>>> +- mmc-ddr-1_2v
>>> +- mmc-hs200-1_8v
>>> +- mmc-hs200-1_2v
>>> +- mmc-hs400-1_8v
>>> +- mmc-hs400-1_2v
>>
>> There's now a property to override SDHCI capabilities register. Maybe
>> you should use that instead? I'll defer to Ulf.
>>
>
> I did not know this new property.
>
> So, now we have two ways to specify MMC speed mode capabilities
> by only touching DT.

Let me clarify a bit.

The point with the new bindings is to be able to override *broken*
SDHCI caps bits. So, not only related to the speed modes.

>
> [1] Add MMC mode flags directly, like I did.
> [2] Use "sdhci-caps-mask" and "sdhci-caps"
>
>
> The problem for [2] is that eMMC capabilities
> do not perfectly correspond to the SDHCI capabilities register.
>
>
>>> +- mmc-hs400-1_8v
>>> +- mmc-hs400-1_2v
>
> If the driver sets SDHCI_QUIRK2_CAPS_BIT63_FOR_HS400,
> we can use the bit63 of caps for specifying HS400.
>
> But, this is not defined in the SDHCI standard.
> #define  SDHCI_SUPPORT_HS400 0x8000 /* Non-standard */
>
>
>
>>> +- mmc-ddr-1_8v
>
> For High Speed DDR, perhaps we can imply MMC_CAP_1_8V_DDR
> from MMC_CAP_UHS_DDR50  (bit34 of caps)
>
> This is not supported in the current code, but
> if this is a good idea, I can send a patch.
>
>
>>> +- mmc-ddr-1_2v
>
> This does not have the corresponding bit, but
> 1.2V is not commonly used, so this is not a fatal problem.
>
>
>
> What I can do at most now, is to delete the
> Optional properties section entirely
> so users can choose [1] or [2] as they like.
>

I think a better approach is to use the new sdhci-caps* bindings to
mask those caps that can't be trusted. And then use the generic mmc
bindings for speed modes instead.

That should be a safer approach, right!?

Kind regards
Uffe


Re: [PATCH] clk: imx: pllv3: support fractional multiplier on vf610 PLL1/PLL2

2016-12-12 Thread Nikita Yushchenko
>> diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
>> index 19f9b622981a..24a9e914e0d5 100644
>> --- a/drivers/clk/imx/clk-pllv3.c
>> +++ b/drivers/clk/imx/clk-pllv3.c
>> @@ -288,6 +291,87 @@ static const struct clk_ops clk_pllv3_av_ops = {
>>  .set_rate   = clk_pllv3_av_set_rate,
>>  };
>>  
>> +static unsigned long clk_pllv3_vf610_recalc_rate(struct clk_hw *hw,
>> +  unsigned long parent_rate)
>> +{
>> +struct clk_pllv3 *pll = to_clk_pllv3(hw);
>> +u32 mfn = readl_relaxed(pll->base + PLL_VF610_NUM_OFFSET);
>> +u32 mfd = readl_relaxed(pll->base + PLL_VF610_DENOM_OFFSET);
>> +u32 div = (readl_relaxed(pll->base) & pll->div_mask) ? 22 : 20;

Should be not 'div' but 'mfi' to be consistent with datasheet and with
other routines in the same patch. Will fix.


Re: netlink: GPF in sock_sndtimeo

2016-12-12 Thread Richard Guy Briggs
On 2016-12-09 23:40, Cong Wang wrote:
> On Fri, Dec 9, 2016 at 8:13 PM, Cong Wang  wrote:
> > On Fri, Dec 9, 2016 at 3:01 AM, Richard Guy Briggs  wrote:
> >> On 2016-12-08 22:57, Cong Wang wrote:
> >>> On Thu, Dec 8, 2016 at 10:02 PM, Richard Guy Briggs  
> >>> wrote:
> >>> > I also tried to extend Cong Wang's idea to attempt to proactively 
> >>> > respond to a
> >>> > NETLINK_URELEASE on the audit_sock and reset it, but ran into a locking 
> >>> > error
> >>> > stack dump using mutex_lock(_cmd_mutex) in the notifier callback.
> >>> > Eliminating the lock since the sock is dead anways eliminates the error.
> >>> >
> >>> > Is it safe?  I'll resubmit if this looks remotely sane.  Meanwhile I'll 
> >>> > try to
> >>> > get the test case to compile.
> >>>
> >>> It doesn't look safe, because 'audit_sock', 'audit_nlk_portid' and 
> >>> 'audit_pid'
> >>> are updated as a whole and race between audit_receive_msg() and
> >>> NETLINK_URELEASE.
> >>
> >> This is what I expected and why I originally added the mutex lock in the
> >> callback...  The dumps I got were bare with no wrapper identifying the
> >> process context or specific error, so I'm at a bit of a loss how to
> >> solve this (without thinking more about it) other than instinctively
> >> removing the mutex.
> >
> > Netlink notifier can safely be converted to blocking one, I will send
> > a patch.
> >
> > But I seriously doubt you really need NETLINK_URELEASE here,
> > it adds nothing but overhead, b/c the netlink notifier is called on
> > every netlink socket in the system, but for net exit path, that is
> > relatively a slow path.
> >
> > Also, kauditd_send_skb() needs audit_cmd_mutex too.
> 
> Please let me know what you think about the attached patch?
> 
> Thanks!

> commit a12b43ee814625933ff155c20dc863c59cfcf240
> Author: Cong Wang 
> Date:   Fri Dec 9 17:56:42 2016 -0800
> 
> audit: close a race condition on audit_sock
> 
> Signed-off-by: Cong Wang 
> 
> diff --git a/kernel/audit.c b/kernel/audit.c
> index f1ca116..ab947d8 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -423,6 +423,8 @@ static void kauditd_send_skb(struct sk_buff *skb)
>   snprintf(s, sizeof(s), "audit_pid=%d reset", 
> audit_pid);
>   audit_log_lost(s);
>   audit_pid = 0;
> + audit_nlk_portid = 0;
> + sock_put(audit_sock);
>   audit_sock = NULL;
>   } else {
>   pr_warn("re-scheduling(#%d) write to 
> audit_pid=%d\n",
> @@ -899,6 +901,9 @@ static int audit_receive_msg(struct sk_buff *skb, struct 
> nlmsghdr *nlh)
>   audit_log_config_change("audit_pid", new_pid, 
> audit_pid, 1);
>   audit_pid = new_pid;
>   audit_nlk_portid = NETLINK_CB(skb).portid;
> + sock_hold(skb->sk);
> + if (audit_sock)
> + sock_put(audit_sock);
>   audit_sock = skb->sk;
>   }
>   if (s.mask & AUDIT_STATUS_RATE_LIMIT) {
> @@ -1167,10 +1172,6 @@ static void __net_exit audit_net_exit(struct net *net)
>  {
>   struct audit_net *aunet = net_generic(net, audit_net_id);
>   struct sock *sock = aunet->nlsk;
> - if (sock == audit_sock) {
> - audit_pid = 0;
> - audit_sock = NULL;
> - }

So how does this not leak memory leaving the sock refcount incremented
by the registered audit daemon when that daemon shuts down normally?


- RGB

--
Richard Guy Briggs 
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635


Re: [PATCH] clk: imx: pllv3: support fractional multiplier on vf610 PLL1/PLL2

2016-12-12 Thread Nikita Yushchenko
>> diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
>> index 19f9b622981a..24a9e914e0d5 100644
>> --- a/drivers/clk/imx/clk-pllv3.c
>> +++ b/drivers/clk/imx/clk-pllv3.c
>> @@ -288,6 +291,87 @@ static const struct clk_ops clk_pllv3_av_ops = {
>>  .set_rate   = clk_pllv3_av_set_rate,
>>  };
>>  
>> +static unsigned long clk_pllv3_vf610_recalc_rate(struct clk_hw *hw,
>> +  unsigned long parent_rate)
>> +{
>> +struct clk_pllv3 *pll = to_clk_pllv3(hw);
>> +u32 mfn = readl_relaxed(pll->base + PLL_VF610_NUM_OFFSET);
>> +u32 mfd = readl_relaxed(pll->base + PLL_VF610_DENOM_OFFSET);
>> +u32 div = (readl_relaxed(pll->base) & pll->div_mask) ? 22 : 20;
>> +u64 temp64 = (u64)parent_rate;
> 
> Useless cast, please remove.

Ok

>> +
>> +temp64 *= mfn;
>> +do_div(temp64, mfd);
>> +
>> +return (parent_rate * div) + (u32)temp64;
>> +}
>> +
>> +static long clk_pllv3_vf610_round_rate(struct clk_hw *hw, unsigned long 
>> rate,
>> +unsigned long *prate)
>> +{
>> +unsigned long parent_rate = *prate;
>> +unsigned int mfi = (rate >= 22 * parent_rate) ? 22 : 20;
> 
> What is the importance of 22 and 20? Hint, at the least it needs
> a comment.

These come directly from datasheet:

Frequency multipler selection (MFI).
0: Fout = Fref * 20
1: Fout = Fref * 22

These numbers (20 / 22) are common among flavours of pllv3 hardware.
In similar places in the same file (e.g. in clk_pllv3_recalc_rate(), in
clk_pllv3_set_rate() ,etc) there are no comments explaining them.

Are you sure this place is special and comment is needed here?

>> +u32 mfn, mfd = 0x3fff;
>> +u64 temp64;
>> +
>> +if (rate <= parent_rate * mfi)
>> +mfn = 0;
>> +else if (rate >= parent_rate * (mfi + 1))
>> +mfn = mfd - 1;
>> +else {
>> +/* rate = parent_rate * (mfi + mfn/mfd) */
>> +temp64 = rate - parent_rate * mfi;
>> +temp64 *= mfd;
>> +do_div(temp64, parent_rate);
>> +mfn = temp64;
>> +}
>> +
>> +temp64 = ((u64)mfd * mfi + mfn) * parent_rate;
>> +do_div(temp64, mfd);
>> +return (u32)temp64;
> 
> Do we need the cast here for some reason?

Just for readability, can remove if it hurts.

>> +}
>> +
>> +static int clk_pllv3_vf610_set_rate(struct clk_hw *hw, unsigned long rate,
>> +unsigned long parent_rate)
>> +{
>> +struct clk_pllv3 *pll = to_clk_pllv3(hw);
>> +unsigned int mfi = (rate >= 22 * parent_rate) ? 22 : 20;
>> +u32 val, mfn, mfd = 0x3fff;
>> +u64 temp64;
>> +
>> +if (rate <= parent_rate * mfi)
>> +mfn = 0;
>> +else if (rate >= parent_rate * (mfi + 1))
>> +mfn = mfd - 1;
>> +else {
>> +/* rate = parent_rate * (mfi + mfn/mfd) */
>> +temp64 = rate - parent_rate * mfi;
>> +temp64 *= mfd;
>> +do_div(temp64, parent_rate);
>> +mfn = temp64;
>> +}
>> +
>> +val = readl_relaxed(pll->base);
>> +if (mfi == 20)
> 
> Presumably this is another place 20 and 22 are special.

See my reply above. Same applies here.

Nikita


[PATCH v5 1/2] usb: host: plat: Enable xhci plat runtime PM

2016-12-12 Thread Baolin Wang
Enable the xhci plat runtime PM for parent device to suspend/resume xhci.
Also call pm_runtime_get_noresume() in probe() function in case the parent
device doesn't call suspend/resume callback by runtime PM now.

Signed-off-by: Baolin Wang 
---
Changes since v4:
 - No updates.

Changes since v3:
 - Fix kbuild error.

Changes since v2:
 - Add pm_runtime_get_noresume() in probe() function.
 - Add pm_runtime_set_suspended()/pm_runtime_put_noidle() in remove() function.

Changes since v1:
 - No updates.
---
 drivers/usb/host/xhci-plat.c |   41 -
 1 file changed, 36 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index ed56bf9..5805c6a 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -246,6 +246,10 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (ret)
goto dealloc_usb2_hcd;
 
+   pm_runtime_get_noresume(>dev);
+   pm_runtime_set_active(>dev);
+   pm_runtime_enable(>dev);
+
return 0;
 
 
@@ -274,6 +278,10 @@ static int xhci_plat_remove(struct platform_device *dev)
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct clk *clk = xhci->clk;
 
+   pm_runtime_set_suspended(>dev);
+   pm_runtime_put_noidle(>dev);
+   pm_runtime_disable(>dev);
+
usb_remove_hcd(xhci->shared_hcd);
usb_phy_shutdown(hcd->usb_phy);
 
@@ -311,14 +319,37 @@ static int xhci_plat_resume(struct device *dev)
 
return xhci_resume(xhci, 0);
 }
+#endif /* CONFIG_PM_SLEEP */
+
+#ifdef CONFIG_PM
+static int xhci_plat_runtime_suspend(struct device *dev)
+{
+   struct usb_hcd  *hcd = dev_get_drvdata(dev);
+   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+
+   return xhci_suspend(xhci, device_may_wakeup(dev));
+}
+
+static int xhci_plat_runtime_resume(struct device *dev)
+{
+   struct usb_hcd  *hcd = dev_get_drvdata(dev);
+   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+
+   return xhci_resume(xhci, 0);
+}
+
+static int xhci_plat_runtime_idle(struct device *dev)
+{
+   return 0;
+}
+#endif /* CONFIG_PM */
 
 static const struct dev_pm_ops xhci_plat_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(xhci_plat_suspend, xhci_plat_resume)
+
+   SET_RUNTIME_PM_OPS(xhci_plat_runtime_suspend, xhci_plat_runtime_resume,
+  xhci_plat_runtime_idle)
 };
-#define DEV_PM_OPS (_plat_pm_ops)
-#else
-#define DEV_PM_OPS NULL
-#endif /* CONFIG_PM */
 
 static const struct acpi_device_id usb_xhci_acpi_match[] = {
/* XHCI-compliant USB Controller */
@@ -332,7 +363,7 @@ static int xhci_plat_resume(struct device *dev)
.remove = xhci_plat_remove,
.driver = {
.name = "xhci-hcd",
-   .pm = DEV_PM_OPS,
+   .pm = _plat_pm_ops,
.of_match_table = of_match_ptr(usb_xhci_of_match),
.acpi_match_table = ACPI_PTR(usb_xhci_acpi_match),
},
-- 
1.7.9.5



[PATCH v5 2/2] usb: dwc3: core: Support the dwc3 host suspend/resume

2016-12-12 Thread Baolin Wang
For some mobile devices with strict power management, we also want to suspend
the host when the slave is detached for power saving. Thus we add the host
suspend/resume functions to support this requirement.

Signed-off-by: Baolin Wang 
---
Changes since v4:
 - Remove Kconfig and just enable host suspend/resume.
 - Simplify the dwc3_host_suspend/resume() function.

Changes since v3:
 - No updates.

Changes since v2:
 - Remove pm_children_suspended() and other unused macros.

Changes since v1:
 - Add pm_runtime.h head file to avoid kbuild error.
---
 drivers/usb/dwc3/core.c |   26 +-
 drivers/usb/dwc3/core.h |7 +++
 drivers/usb/dwc3/host.c |   21 +
 3 files changed, 53 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 9a4a5e4..7ad4bc3 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1091,6 +1091,7 @@ static int dwc3_probe(struct platform_device *pdev)
pm_runtime_use_autosuspend(dev);
pm_runtime_set_autosuspend_delay(dev, DWC3_DEFAULT_AUTOSUSPEND_DELAY);
pm_runtime_enable(dev);
+   pm_suspend_ignore_children(dev, true);
ret = pm_runtime_get_sync(dev);
if (ret < 0)
goto err1;
@@ -1215,15 +1216,27 @@ static int dwc3_remove(struct platform_device *pdev)
 static int dwc3_suspend_common(struct dwc3 *dwc)
 {
unsigned long   flags;
+   int ret;
 
switch (dwc->dr_mode) {
case USB_DR_MODE_PERIPHERAL:
+   spin_lock_irqsave(>lock, flags);
+   dwc3_gadget_suspend(dwc);
+   spin_unlock_irqrestore(>lock, flags);
+   break;
case USB_DR_MODE_OTG:
+   ret = dwc3_host_suspend(dwc);
+   if (ret)
+   return ret;
+
spin_lock_irqsave(>lock, flags);
dwc3_gadget_suspend(dwc);
spin_unlock_irqrestore(>lock, flags);
break;
case USB_DR_MODE_HOST:
+   ret = dwc3_host_suspend(dwc);
+   if (ret)
+   return ret;
default:
/* do nothing */
break;
@@ -1245,12 +1258,23 @@ static int dwc3_resume_common(struct dwc3 *dwc)
 
switch (dwc->dr_mode) {
case USB_DR_MODE_PERIPHERAL:
+   spin_lock_irqsave(>lock, flags);
+   dwc3_gadget_resume(dwc);
+   spin_unlock_irqrestore(>lock, flags);
+   break;
case USB_DR_MODE_OTG:
+   ret = dwc3_host_resume(dwc);
+   if (ret)
+   return ret;
+
spin_lock_irqsave(>lock, flags);
dwc3_gadget_resume(dwc);
spin_unlock_irqrestore(>lock, flags);
-   /* FALLTHROUGH */
+   break;
case USB_DR_MODE_HOST:
+   ret = dwc3_host_resume(dwc);
+   if (ret)
+   return ret;
default:
/* do nothing */
break;
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index b585a30..1099168 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -1158,11 +1158,18 @@ static inline bool dwc3_is_usb31(struct dwc3 *dwc)
 #if IS_ENABLED(CONFIG_USB_DWC3_HOST) || IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE)
 int dwc3_host_init(struct dwc3 *dwc);
 void dwc3_host_exit(struct dwc3 *dwc);
+int dwc3_host_suspend(struct dwc3 *dwc);
+int dwc3_host_resume(struct dwc3 *dwc);
 #else
 static inline int dwc3_host_init(struct dwc3 *dwc)
 { return 0; }
 static inline void dwc3_host_exit(struct dwc3 *dwc)
 { }
+
+static inline int dwc3_host_suspend(struct dwc3 *dwc)
+{ return 0; }
+static inline int dwc3_host_resume(struct dwc3 *dwc)
+{ return 0; }
 #endif
 
 #if IS_ENABLED(CONFIG_USB_DWC3_GADGET) || IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE)
diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index ed82464..7959ef0 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -16,6 +16,7 @@
  */
 
 #include 
+#include 
 
 #include "core.h"
 
@@ -130,3 +131,23 @@ void dwc3_host_exit(struct dwc3 *dwc)
  dev_name(>xhci->dev));
platform_device_unregister(dwc->xhci);
 }
+
+int dwc3_host_suspend(struct dwc3 *dwc)
+{
+   struct device *xhci = >xhci->dev;
+
+   /*
+* Note: if we get the -EBUSY, which means the xHCI children devices are
+* not in suspend state yet, the glue layer need to wait for a while and
+* try to suspend xHCI device again.
+*/
+   return pm_runtime_put_sync(xhci);
+}
+
+int dwc3_host_resume(struct dwc3 *dwc)
+{
+   struct device *xhci = >xhci->dev;
+
+   /* Resume the xHCI device synchronously. */
+   return pm_runtime_get_sync(xhci);
+}
-- 
1.7.9.5



Re: epoll_wait inaccurate timeout

2016-12-12 Thread Dmitry Banschikov
On Mon, Dec 12, 2016 at 2:34 PM, Eric Wong  wrote:
> +Cc folks who may know about timer stuff on epoll.
>
> Dmitry Banschikov  wrote:
>> Hi!
>>
>> I have a problem caused by inaccurate timeouts in epoll_wait(2).
>> Here are some parts of strace -tt output:
>
> Which kernel version are you using?

I was able to reproduce this problem in 4.4.0(Ubuntu 16.04) and
3.10.0(CentOS 7.2.1511) on
two different x86_64 machines.

>
>> 22578 09:33:46.959791 epoll_wait(5,  
>> 22578 09:33:50.010794 <... epoll_wait resumed> [], 128, 1498) = 0
>> ...
>> 22034 09:35:07.686896 epoll_wait(5,  
>> 22034 09:35:09.482526 <... epoll_wait resumed> [{EPOLLIN,
>> {u32=151458248, u64=151458248}}], 128, 362) = 1
>> ...
>> 22036 09:35:41.433241 epoll_wait(5,  
>> 22036 09:35:43.176881 <... epoll_wait resumed> [], 128, 97) = 0
>>
>> In each example epoll_wait is blocked for too longer then asked in timeout.
>>
>> Is it normal?
>
> I don't think so, unless you have a huge /proc//timerslack_ns
> set.  But I mainly use -1 or 0 as the timeout value.

/proc//timerslack_ns interface was added in 4.6.
For sure I can try to reproduce problem on fresh kernel if it can help
debugging.

I observe such epoll_wait behavior quite rarely - usually
one/two/three times per
hours of attempts to reproduce. And from strace output I can see that
system is not in state of resource starvation - because other threads
do some work
between call and return to/from epoll_wait.

Such timeout values for epoll_wait are generated by Boost ASIO library.
Internally it uses priority queue for storing timer events and use timeout to
nearest event from queue in epoll_wait.

What information can help to debug this issue?


>
>> Please CC me.
>
> That's standard procedure, here :)



-- 

Dmitry Banschikov


[PATCHv2 4/5] perf tools: Allow to ignore missing pid

2016-12-12 Thread Jiri Olsa
On Tue, Dec 13, 2016 at 01:58:25AM +0900, Namhyung Kim wrote:

SNIP

> >  }
> >  
> > +static bool ignore_missing_thread(struct perf_evsel *evsel,
> > + struct thread_map *threads,
> > + int thread, int err)
> > +{
> > +   if (!evsel->ignore_missing_thread)
> > +   return false;
> > +
> > +   /* The system wide setup does not work with threads. */
> > +   if (!evsel->system_wide)
> > +   return false;
> 
> I'm bit confused with this.  Shouldn't the condition be positive?
> 

ugh, right.. that was last minute change, I had this condition
below together with ignore_missing_thread call and moved it up :-\

thanks for spotting this, attaching v2

jirka


---
Adding perf_evsel::ignore_missing_cpu_thread bool.

When set true, it allows perf to ignore error of missing
pid of perf event syscall.

We remove missing thread id from the thread_map, so the
rest of the processing like ioctl and mmap won't get
disturbed with -1 fd.

The reason for supporting this is to ease up monitoring
group of pids, that 'disappear' before perf opens their
event. This currently leads perf to report error and exit
and makes perf record's -u option unusable under certain
setup.

With this change we will allow this race and ignore such
failure with following warning:

  WARNING: Ignored open failure for pid 8605

Signed-off-by: Jiri Olsa 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/n/tip-atmzsjyhrt1j6xjwwmb84...@git.kernel.org
---
 tools/perf/perf.h   |  1 +
 tools/perf/util/evsel.c | 44 
 tools/perf/util/evsel.h |  1 +
 3 files changed, 46 insertions(+)

diff --git a/tools/perf/perf.h b/tools/perf/perf.h
index 9a0236a4cf95..1c27d947c2fe 100644
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -55,6 +55,7 @@ struct record_opts {
bool all_user;
bool tail_synthesize;
bool overwrite;
+   bool ignore_missing_thread;
unsigned int freq;
unsigned int mmap_pages;
unsigned int auxtrace_mmap_pages;
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index fd61ebd77c26..04e536ae4d88 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -990,6 +990,8 @@ void perf_evsel__config(struct perf_evsel *evsel, struct 
record_opts *opts,
 * it overloads any global configuration.
 */
apply_config_terms(evsel, opts);
+
+   evsel->ignore_missing_thread = opts->ignore_missing_thread;
 }
 
 static int perf_evsel__alloc_fd(struct perf_evsel *evsel, int ncpus, int 
nthreads)
@@ -1419,6 +1421,33 @@ static int __open_attr__fprintf(FILE *fp, const char 
*name, const char *val,
return fprintf(fp, "  %-32s %s\n", name, val);
 }
 
+static bool ignore_missing_thread(struct perf_evsel *evsel,
+ struct thread_map *threads,
+ int thread, int err)
+{
+   if (!evsel->ignore_missing_thread)
+   return false;
+
+   /* The system wide setup does not work with threads. */
+   if (evsel->system_wide)
+   return false;
+
+   /* The -ESRCH is perf event syscall errno for pid's not found. */
+   if (err != -ESRCH)
+   return false;
+
+   /* If there's only one thread, let it fail. */
+   if (threads->nr == 1)
+   return false;
+
+   if (thread_map__remove(threads, thread))
+   return false;
+
+   pr_warning("WARNING: Ignored open failure for pid %d\n",
+  thread_map__pid(threads, thread));
+   return true;
+}
+
 static int __perf_evsel__open(struct perf_evsel *evsel, struct cpu_map *cpus,
  struct thread_map *threads)
 {
@@ -1491,6 +1520,21 @@ static int __perf_evsel__open(struct perf_evsel *evsel, 
struct cpu_map *cpus,
 
if (fd < 0) {
err = -errno;
+
+   if (ignore_missing_thread(evsel, threads, 
thread, err)) {
+   /*
+* We just removed 1 thread, so take a 
step
+* back on thread index and lower the 
upper
+* nthreads limit.
+*/
+   nthreads--;
+   thread--;
+
+   /* ... and pretend like nothing have 
happened. */
+   err = 0;
+   continue;
+   }
+
pr_debug2("\nsys_perf_event_open failed, error 
%d\n",
  err);

Re: [PATCH] Input: ar1021-i2c - fix too long name in driver's device table

2016-12-12 Thread Christian Gmeiner
2016-12-13 0:57 GMT+01:00 Dmitry Torokhov :
> The name field in structure i2c_device_id is 20 characters, and we
> expect it to be NULL-terminated, however we are trying to stuff it with
> 21 bytes and thus NULL-terminator is lost. This causes issues when one
> creates device with name "MICROCHIP_AR1021_I2C" as i2c core cuts off the
> last "C", and automatic module loading by alias does not work as result.
>
> The -I2C suffix in the device name is superfluous, we know what bus we
> are dealing with, so let's drop it.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116211
> Signed-off-by: Dmitry Torokhov 
> ---
>  drivers/input/touchscreen/ar1021_i2c.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/touchscreen/ar1021_i2c.c 
> b/drivers/input/touchscreen/ar1021_i2c.c
> index 71b5a63..89f9587 100644
> --- a/drivers/input/touchscreen/ar1021_i2c.c
> +++ b/drivers/input/touchscreen/ar1021_i2c.c
> @@ -152,7 +152,7 @@ static int __maybe_unused ar1021_i2c_resume(struct device 
> *dev)
>  static SIMPLE_DEV_PM_OPS(ar1021_i2c_pm, ar1021_i2c_suspend, 
> ar1021_i2c_resume);
>
>  static const struct i2c_device_id ar1021_i2c_id[] = {
> -   { "MICROCHIP_AR1021_I2C", 0 },
> +   { "MICROCHIP_AR1021", 0 },
> { },
>  };
>  MODULE_DEVICE_TABLE(i2c, ar1021_i2c_id);
> --
> 2.8.0.rc3.226.g39d4020
>

Reviewed-By: Christian Gmeiner 


Re: [PATCH] clk: imx: pllv3: support fractional multiplier on vf610 PLL1/PLL2

2016-12-12 Thread Stephen Boyd
On 12/09, Nikita Yushchenko wrote:
> diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
> index 19f9b622981a..24a9e914e0d5 100644
> --- a/drivers/clk/imx/clk-pllv3.c
> +++ b/drivers/clk/imx/clk-pllv3.c
> @@ -288,6 +291,87 @@ static const struct clk_ops clk_pllv3_av_ops = {
>   .set_rate   = clk_pllv3_av_set_rate,
>  };
>  
> +static unsigned long clk_pllv3_vf610_recalc_rate(struct clk_hw *hw,
> +   unsigned long parent_rate)
> +{
> + struct clk_pllv3 *pll = to_clk_pllv3(hw);
> + u32 mfn = readl_relaxed(pll->base + PLL_VF610_NUM_OFFSET);
> + u32 mfd = readl_relaxed(pll->base + PLL_VF610_DENOM_OFFSET);
> + u32 div = (readl_relaxed(pll->base) & pll->div_mask) ? 22 : 20;
> + u64 temp64 = (u64)parent_rate;

Useless cast, please remove.

> +
> + temp64 *= mfn;
> + do_div(temp64, mfd);
> +
> + return (parent_rate * div) + (u32)temp64;
> +}
> +
> +static long clk_pllv3_vf610_round_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long *prate)
> +{
> + unsigned long parent_rate = *prate;
> + unsigned int mfi = (rate >= 22 * parent_rate) ? 22 : 20;

What is the importance of 22 and 20? Hint, at the least it needs
a comment.

> + u32 mfn, mfd = 0x3fff;
> + u64 temp64;
> +
> + if (rate <= parent_rate * mfi)
> + mfn = 0;
> + else if (rate >= parent_rate * (mfi + 1))
> + mfn = mfd - 1;
> + else {
> + /* rate = parent_rate * (mfi + mfn/mfd) */
> + temp64 = rate - parent_rate * mfi;
> + temp64 *= mfd;
> + do_div(temp64, parent_rate);
> + mfn = temp64;
> + }
> +
> + temp64 = ((u64)mfd * mfi + mfn) * parent_rate;
> + do_div(temp64, mfd);
> + return (u32)temp64;

Do we need the cast here for some reason?

> +}
> +
> +static int clk_pllv3_vf610_set_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long parent_rate)
> +{
> + struct clk_pllv3 *pll = to_clk_pllv3(hw);
> + unsigned int mfi = (rate >= 22 * parent_rate) ? 22 : 20;
> + u32 val, mfn, mfd = 0x3fff;
> + u64 temp64;
> +
> + if (rate <= parent_rate * mfi)
> + mfn = 0;
> + else if (rate >= parent_rate * (mfi + 1))
> + mfn = mfd - 1;
> + else {
> + /* rate = parent_rate * (mfi + mfn/mfd) */
> + temp64 = rate - parent_rate * mfi;
> + temp64 *= mfd;
> + do_div(temp64, parent_rate);
> + mfn = temp64;
> + }
> +
> + val = readl_relaxed(pll->base);
> + if (mfi == 20)

Presumably this is another place 20 and 22 are special.

> + val &= ~pll->div_mask;
> + else
> + val |= pll->div_mask;
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


Re: [PATCH 3/5] firmware: revamp firmware documentation

2016-12-12 Thread Rafał Miłecki

On 12/13/2016 04:08 AM, Luis R. Rodriguez wrote:

Understanding this code is getting out of control without any
notes. Give the firmware_class driver a much needed documentation love,
and while at it convert it to the new sphinx documentation format.


It does help to understand the class/API, thank you!



+Even if you have these needs there are a few reasons why you may not be
+able to make use of built-in firmware:
+
+* Legalese - firmware is non-GPL compatible
+* Some firmware may be optional
+* Firmware upgrades are possible, therefore a new firmware would implicate
+  a complete firmware rebuild.


Could it be you meant "kernel rebuild" or "vmlinux rebuild" here?



diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst 
b/Documentation/driver-api/firmware/fallback-mechanisms.rst
new file mode 100644
index ..edce1d76ce29
--- /dev/null
+++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst
@@ -0,0 +1,195 @@
+===
+Fallback mechanisms
+===
+
+A fallback mechanism is supported to allow to overcome failures to do a direct
+filesystem lookup on the root filesystem or when the firmware simply cannot be
+installed for practical reasons on the root filesystem. The kernel
+configuration options related to supporting the firmware fallback mechanism 
are:
+
+  * CONFIG_FW_LOADER_USER_HELPER: enables building the firmware fallback
+mechanism. Most distributions enable this option today. If enabled but
+CONFIG_FW_LOADER_USER_HELPER_FALLBACK is disabled, only the custom fallback
+mechanism is available and for the request_firmware_nowait() call.
+  * CONFIG_FW_LOADER_USER_HELPER_FALLBACK: force enables each request to
+enable the kobject uevent fallback mechanism on all firmare API calls
+except request_firmware_direct(). Most distributions disable this option
+today. The call request_firmware_nowait() allows for one alternative
+fallback mechanism: if this kconfig option is enabled and your second
+argument to request_firmware_nowait(), uevent, is set to false you are
+informing the kernel that you have a custom fallback mechanism and it will
+manually load the firmware. Read below for more details.


Yeah, it really asks for API simplification ;)


Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

2016-12-12 Thread Nicholas Piggin
On Mon, 12 Dec 2016 10:48:47 +0100
Stanislav Kozina  wrote:

>  A runtime check is still done, with per-module vermagic which distros
>  can change when they bump the ABI version. Is it really necessary to
>  have more than that (i.e., per-symbol versioning)?  
> >>>   From my point of view, it is. We need to allow changing ABI for some
> >>> modules while maintaining it for others.
> >>> In fact I think that there should be version not only for every exported
> >>> symbol (in the EXPORT_SYMBOL() sense), but also for every public type
> >>> (in the sense of eg. structure defined in the public header file).  
> >> Well the distro can just append _v2, _v3 to the name of the function
> >> or type if it has to break compat for some reason. Would that be enough?  
> > There are other ways that distros can work around when upstream "breaks"
> > the ABI, sometimes they can rename functions, and others they can
> > "preload" structures with padding in anticipation for when/if fields get
> > added to them.  But that's all up to the distros, no need for us to
> > worry about that at all :)  
> 
> Currently, the ABI version (checksum) is stored outside of the actual 
> code in the __ksymtab section. That means that the distributions can 
> still apply upstream patches cleanly and only update the version 
> checksum if these break ABI.
> 
> With the _v2, _v3 suffixes (or similar solutions) we'd be effectively 
> storing the ABI versions directly in the code and that would cause 
> conflicts when pulling further patches from upstream.
> 
> My view is that it would be than easier to maintain out-of-tree 
> modversions (or similar tool) rather than to solve all these conflicts.

That kind of name clash should hardly be an issue, in comparison with the
care it requires to merge fixes on top of a backport which has already
changed ABI. It tends to be trivially fixable just by search/replace
in the patchfile before applying, if nothing else. But you probably *want*
to be flagged on those things and merge by hand anyway.

Backporting alone I don't think can justify symbol versioning, but I'd
like to hear from distro maintainers if any disagree.

Thanks,
Nick


Issue with DRM and "reimplement IDR and IDA using the radix tree"

2016-12-12 Thread Alexandre Courbot
Hi Matthew,

Trying the latest -next on the Jetson TK1 board (with two different DRM
devices and display and render), I noticed that the GPU device probe
always failed with error -ENOSPC. After investigating I figured out that
this was due to the minor device allocation failing when a second DRM
device is added.

More precisely, when drm_minor_alloc() is called with DRM_MINOR_PRIMARY
(0) as argument for a second time, the call to idr_alloc() (which has a
requested range of 0..64) fails instead of returning 1 as expected. Note
that the first call is successful.

Reverting "reimplement IDR and IDA using the radix tree" on 20161213's
next fixes the issue for me, suggesting a bug may have slipped in there.

Not sure how this could be fixed, so reporting the issue for now in case
it is not known yet.

Cheers,
Alex.


Re: [RFC PATCH 0/3] staging: remove fbdev drivers

2016-12-12 Thread Michel Dänzer
On 10/12/16 05:27 AM, Benjamin Herrenschmidt wrote:
> On Fri, 2016-12-09 at 14:35 +0100, Daniel Vetter wrote:
>>> As for multi userspace client, well, swapping an mmap between HW and
>>> memory backing store is a somewhat solved problem already.
>>
>> Hm, I didn't know that, but then all existing drm drivers have fairly
>> simplistic fbdev mmap implementations.
> 
> Hrm, I though the TTM did it ... I remember talking with Thomas
> Hellstrom about that back in the day... you use unmap_mapping_range
> to unmap the existing mappings basically so you can take new faults
> and route them to a different page, but I can't see a call in there
> so maybe he ended up not doing it.

I think he did, it was working fine for userspace mappings when I tried
making radeon use a non-pinned BO for fbdev years ago (the problem was
fbcon potentially trying to access the framebuffer at the most
inconvenient times). There's still ttm_fbdev_mmap, but I'm not sure
everything to make this fully work for userspace fbdev mappings is still
there.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer


[RFC][PATCH 1/5] usb: dwc2: Avoid sleeping while holding hsotg->lock

2016-12-12 Thread John Stultz
Basically when plugging in various cables in different orders, I'm
occasionally seeing the following BUG splat:

[   86.215403] BUG: scheduling while atomic: kworker/u16:2/53/0x0002
[   86.219164] usb 1-1: USB disconnect, device number 9
[   86.226845] Preemption disabled at:[   86.230218]
[] dwc2_conn_id_status_change+0x120/0x250
[   86.236894] CPU: 0 PID: 53 Comm: kworker/u16:2 Tainted: GW
 4.9.0-rc8-00051-gd5a7979-dirty #1702
[   86.246836] Hardware name: HiKey Development Board (DT)
[   86.252100] Workqueue: dwc2 dwc2_conn_id_status_change
[   86.257279] Call trace:
[   86.259771] [] dump_backtrace+0x0/0x1a0
[   86.265210] [] show_stack+0x14/0x20
[   86.270308] [] dump_stack+0x90/0xb0
[   86.275401] [] __schedule_bug+0x6c/0xb8
[   86.280841] [] __schedule+0x4f8/0x5b0
[   86.286099] [] schedule+0x38/0xa0
[   86.291017] [] schedule_hrtimeout_range_clock+0x8c/0xf0
[   86.297846] [] schedule_hrtimeout_range+0x10/0x18
[   86.304150] [] usleep_range+0x50/0x58
[   86.309418] [] dwc2_wait_for_mode.isra.4+0x54/0xd0
[   86.315815] [] dwc2_core_reset+0xe0/0x168
[   86.321431] [] dwc2_hsotg_core_init_disconnected+0x2c/0x310
[   86.328602] [] dwc2_conn_id_status_change+0x130/0x250
[   86.335254] [] process_one_work+0x118/0x370
[   86.341035] [] worker_thread+0x48/0x498
[   86.346473] [] kthread+0xd0/0xe8
[   86.351299] [] ret_from_fork+0x10/0x50

This seems to be caused by the dwc2_wait_for_mode() calling
usleep_range() while the hstog->lock spinlock is held, since
we take that before calling dwc2_hsotg_core_init_disconnected().

This patch avoids the issue by adding an extra argument to
dwc2_core_reset(), as suggested by John Youn, which allows us to
skip the waiting, which should be unnecessary when calling from
dwc2_hsotg_core_init_disconnected().

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: Rob Herring 
Cc: John Youn 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Kishon Vijay Abraham I 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
Signed-off-by: John Stultz 
---
 drivers/usb/dwc2/core.c   | 6 +++---
 drivers/usb/dwc2/core.h   | 2 +-
 drivers/usb/dwc2/gadget.c | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 4c0fa0b..2e83545 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -313,7 +313,7 @@ static bool dwc2_iddig_filter_enabled(struct dwc2_hsotg 
*hsotg)
  * Do core a soft reset of the core.  Be careful with this because it
  * resets all the internal state machines of the core.
  */
-int dwc2_core_reset(struct dwc2_hsotg *hsotg)
+int dwc2_core_reset(struct dwc2_hsotg *hsotg, bool skip_wait)
 {
u32 greset;
int count = 0;
@@ -369,7 +369,7 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
}
} while (!(greset & GRSTCTL_AHBIDLE));
 
-   if (wait_for_host_mode)
+   if (wait_for_host_mode && !skip_wait)
dwc2_wait_for_mode(hsotg, true);
 
return 0;
@@ -500,7 +500,7 @@ int dwc2_core_reset_and_force_dr_mode(struct dwc2_hsotg 
*hsotg)
 {
int retval;
 
-   retval = dwc2_core_reset(hsotg);
+   retval = dwc2_core_reset(hsotg, false);
if (retval)
return retval;
 
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 2a21a04..963ea1b 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -1020,7 +1020,7 @@ enum dwc2_halt_status {
  * The following functions support initialization of the core driver component
  * and the DWC_otg controller
  */
-extern int dwc2_core_reset(struct dwc2_hsotg *hsotg);
+extern int dwc2_core_reset(struct dwc2_hsotg *hsotg, bool skip_wait);
 extern int dwc2_core_reset_and_force_dr_mode(struct dwc2_hsotg *hsotg);
 extern int dwc2_enter_hibernation(struct dwc2_hsotg *hsotg);
 extern int dwc2_exit_hibernation(struct dwc2_hsotg *hsotg, bool restore);
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 24fbebc..0bda799 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2521,7 +2521,7 @@ void dwc2_hsotg_core_init_disconnected(struct dwc2_hsotg 
*hsotg,
kill_all_requests(hsotg, hsotg->eps_out[0], -ECONNRESET);
 
if (!is_usb_reset)
-   if (dwc2_core_reset(hsotg))
+   if (dwc2_core_reset(hsotg, true))
return;
 
/*
-- 
2.7.4



[RFC][PATCH 4/5] usb: dwc2: Avoid suspending if we're in gadget mode

2016-12-12 Thread John Stultz
I've found when booting HiKey with the usb gadget cable attached
if I then try to connect via adb, I get an infinite spew of:

dwc2 f72c.usb: dwc2_hsotg_ep_sethalt(ep ffc0790ecb18 ep1out, 0)
dwc2 f72c.usb: dwc2_hsotg_ep_sethalt(ep ffc0790eca18 ep1in, 0)

It seems that the usb autosuspend is suspending the bus shortly
after bootup when the gadget cable is attached. So when adbd
then tries to use the device, it doesn't work and it then tries
to restart it over and over via the ep_sethalt calls (via
FUNCTIONFS_CLEAR_HALT ioctl).

Chen Yu suggested this patch to avoid suspending if we're
in device mode, and it avoids the problem.

This doesn't remove the need for the previous patch, to resume
the port when we switch to gadget mode from host mode. But it
does seem to resolve the issue.

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: Rob Herring 
Cc: John Youn 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Kishon Vijay Abraham I 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
Suggested-by: Chen Yu 
Signed-off-by: John Stultz 
---
 drivers/usb/dwc2/hcd.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 24db997..008f5bc 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -4375,6 +4375,9 @@ static int _dwc2_hcd_suspend(struct usb_hcd *hcd)
if (!HCD_HW_ACCESSIBLE(hcd))
goto unlock;
 
+   if (hsotg->op_state == OTG_STATE_B_PERIPHERAL)
+   goto unlock;
+
if (!hsotg->core_params->hibernation)
goto skip_power_saving;
 
-- 
2.7.4



[RFC][PATCH 2/5] usb: dwc2: Workaround case where GOTGCTL state is wrong

2016-12-12 Thread John Stultz
When removing a USB-A to USB-otg adapter cable, we get a change
status irq, and then in dwc2_conn_id_status_change, we
erroniously see the GOTGCTL_CONID_B flag set. This causes us to
get  stuck in the "while (!dwc2_is_device_mode(hsotg))" loop,
spitting out "Waiting for Peripheral Mode, Mode=Host" warnings
until it fails out many seconds later.

This patch works around the issue by re-reading the GOTGCTL
state to check if the GOTGCTL_CONID_B is still set and if not
restarting the change status logic.

I suspect this isn't the best solution, but it seems to work
well for me.

Feedback would be greatly appreciated!

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: Rob Herring 
Cc: John Youn 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Kishon Vijay Abraham I 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
Acked-by: John Youn 
Signed-off-by: John Stultz 
---
 drivers/usb/dwc2/hcd.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index df5a065..a3f34dd 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -3199,7 +3199,7 @@ static void dwc2_conn_id_status_change(struct work_struct 
*work)
dev_dbg(hsotg->dev, "gotgctl=%0x\n", gotgctl);
dev_dbg(hsotg->dev, "gotgctl.b.conidsts=%d\n",
!!(gotgctl & GOTGCTL_CONID_B));
-
+again:
/* B-Device connector (Device Mode) */
if (gotgctl & GOTGCTL_CONID_B) {
/* Wait for switch to device mode */
@@ -3210,6 +3210,9 @@ static void dwc2_conn_id_status_change(struct work_struct 
*work)
 dwc2_is_host_mode(hsotg) ? "Host" :
 "Peripheral");
usleep_range(2, 4);
+   gotgctl = dwc2_readl(hsotg->regs + GOTGCTL);
+   if (!(gotgctl & GOTGCTL_CONID_B))
+   goto again;
if (++count > 250)
break;
}
-- 
2.7.4



[RFC][PATCH 0/5] Fixes and workarounds for dwc2 on HiKey board

2016-12-12 Thread John Stultz
I just wanted to send out my current queue of patches for dwc2
controller on the HiKey board.

This does exclude my patchset[1] to add extcon support to dwc2,
which John Youn suspects a pending rework of the dwc2 fifo init
logic might make unnecssary.

So in the meantime, I wanted to send out the other patches I
have to use, so that they can get feedback and be consdiered
for the next (4.11) merge window.

Feedback would be greatly appreciated!

thanks
-john

[1] https://lkml.org/lkml/2016/12/6/69

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: Rob Herring 
Cc: John Youn 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Kishon Vijay Abraham I 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org

Chen Yu (2):
  usb: dwc2: Force port resume on switching to device mode
  usb: dwc2: Add a quirk to allow speed negotiation for Hisilicon Hi6220

John Stultz (3):
  usb: dwc2: Avoid sleeping while holding hsotg->lock
  usb: dwc2: Workaround case where GOTGCTL state is wrong
  usb: dwc2: Avoid suspending if we're in gadget mode

 drivers/usb/dwc2/core.c |  6 ++--
 drivers/usb/dwc2/core.h |  8 -
 drivers/usb/dwc2/gadget.c   |  2 +-
 drivers/usb/dwc2/hcd.c  | 75 -
 drivers/usb/dwc2/platform.c |  1 +
 5 files changed, 86 insertions(+), 6 deletions(-)

-- 
2.7.4



[RFC][PATCH 5/5] usb: dwc2: Add a quirk to allow speed negotiation for Hisilicon Hi6220

2016-12-12 Thread John Stultz
From: Chen Yu 

The Hi6220's usb controller is limited in that it does not
support "Split Transactions", so it does not support communicating
with low-speed and full-speed devices behind a high-speed hub.

Thus it requires a quirk so that we can manually drop the usb
speed when low/full-speed are attached, and bump back to high
speed when they are removed.

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: Rob Herring 
Cc: John Youn 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Kishon Vijay Abraham I 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
Signed-off-by: Chen Yu 
[jstultz: Reworked to simplify the patch, and made
 commit log to be more specific about the issue]
Signed-off-by: John Stultz 
---
v2:
* Fix build issue reported by kbuildbot
* Rework to avoid using new dts entry suggested by RobH
* Further tweaks from Chen Yu to try to address comments from
  John Youn
* Further simplified logic
---
 drivers/usb/dwc2/core.h |  6 +
 drivers/usb/dwc2/hcd.c  | 60 +
 drivers/usb/dwc2/platform.c |  1 +
 3 files changed, 67 insertions(+)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 963ea1b..de1fa0c 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -417,6 +417,11 @@ enum dwc2_ep0_state {
  * needed.
  * 0 - No (default)
  * 1 - Yes
+ * @change_speed_quirk: Change speed configuration to DWC2_SPEED_PARAM_FULL
+ *  while full speed device connect. And change speed
+ *  back to DWC2_SPEED_PARAM_HIGH while device is gone.
+ * 0 - No (default)
+ * 1 - Yes
  *
  * The following parameters may be specified when starting the module. These
  * parameters define how the DWC_otg controller should be configured. A
@@ -457,6 +462,7 @@ struct dwc2_core_params {
int uframe_sched;
int external_id_pin_ctl;
int hibernation;
+   int change_speed_quirk;
 };
 
 /**
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 008f5bc..7cf8d8e 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -4873,6 +4873,61 @@ static void _dwc2_hcd_clear_tt_buffer_complete(struct 
usb_hcd *hcd,
spin_unlock_irqrestore(>lock, flags);
 }
 
+/*
+ * HPRT0_SPD_HIGH_SPEED: high speed
+ * HPRT0_SPD_FULL_SPEED: full speed
+ */
+static void dwc2_change_bus_speed(struct usb_hcd *hcd, int speed)
+{
+   struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
+
+   if (hsotg->core_params->speed == speed)
+   return;
+
+   hsotg->core_params->speed = speed;
+   queue_work(hsotg->wq_otg, >wf_otg);
+}
+
+static void dwc2_free_dev(struct usb_hcd *hcd, struct usb_device *udev)
+{
+   struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
+
+   if (!hsotg->core_params->change_speed_quirk)
+   return;
+
+   /*
+* On removal, set speed to default high-speed.
+*/
+   if (udev->parent && udev->parent->speed > USB_SPEED_UNKNOWN &&
+   udev->parent->speed < USB_SPEED_HIGH) {
+   dev_info(hsotg->dev, "Set speed to default high-speed\n");
+   dwc2_change_bus_speed(hcd, HPRT0_SPD_HIGH_SPEED);
+   }
+}
+
+static int dwc2_reset_device(struct usb_hcd *hcd, struct usb_device *udev)
+{
+   struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
+
+   if (!hsotg->core_params->change_speed_quirk)
+   return 0;
+
+   if (udev->speed == USB_SPEED_HIGH) {
+   dev_info(hsotg->dev, "Set speed to high-speed\n");
+   dwc2_change_bus_speed(hcd, HPRT0_SPD_HIGH_SPEED);
+   } else if ((udev->speed == USB_SPEED_FULL ||
+   udev->speed == USB_SPEED_LOW)) {
+   /*
+* Change speed setting to full-speed if there's
+* a full-speed or low-speed device plugged in.
+*/
+   dev_info(hsotg->dev, "Set speed to full-speed\n");
+   dwc2_change_bus_speed(hcd, HPRT0_SPD_FULL_SPEED);
+   }
+
+   return 0;
+}
+
 static struct hc_driver dwc2_hc_driver = {
.description = "dwc2_hsotg",
.product_desc = "DWC OTG Controller",
@@ -5028,6 +5083,11 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
dev_warn(hsotg->dev, "can't set coherent DMA mask\n");
}
 
+   if (hsotg->core_params->change_speed_quirk) {
+   dwc2_hc_driver.free_dev = dwc2_free_dev;
+   dwc2_hc_driver.reset_device = dwc2_reset_device;
+   }
+
hcd = usb_create_hcd(_hc_driver, hsotg->dev, 

[RFC][PATCH 3/5] usb: dwc2: Force port resume on switching to device mode

2016-12-12 Thread John Stultz
From: Chen Yu 

We've seen failures when switching between host and gadget mode,
which was diagnosed as being caused due to the bus being
auto-suspended when we switched.

So this patch forces a port resume when switching to device
mode if the bus is suspended.

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: Rob Herring 
Cc: John Youn 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
Signed-off-by: Chen Yu 
Signed-off-by: John Stultz 
---
 drivers/usb/dwc2/hcd.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index a3f34dd..24db997 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -54,6 +54,8 @@
 #include "core.h"
 #include "hcd.h"
 
+static void dwc2_port_resume(struct dwc2_hsotg *hsotg);
+
 /*
  * =
  *  Host Core Layer Functions
@@ -3204,6 +3206,11 @@ static void dwc2_conn_id_status_change(struct 
work_struct *work)
if (gotgctl & GOTGCTL_CONID_B) {
/* Wait for switch to device mode */
dev_dbg(hsotg->dev, "connId B\n");
+   if (hsotg->bus_suspended) {
+   dev_info(hsotg->dev,
+"Do port resume before switching to device 
mode\n");
+   dwc2_port_resume(hsotg);
+   }
while (!dwc2_is_device_mode(hsotg)) {
dev_info(hsotg->dev,
 "Waiting for Peripheral Mode, Mode=%s\n",
-- 
2.7.4



[GIT PULL] s390 patches for 4.10 merge window #1

2016-12-12 Thread Martin Schwidefsky
Hi Linus,

please pull from the 'for-linus' branch of

git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus

to receive the following updates:

The main bulk of the s390 patches for the 4.10 merge window:

* Add support for the contiguous memory allocator.

* The recovery for I/O errors in the dasd device driver is improved, the
  driver will now remove channel paths that are not working properly.

* Additional fields are added to /proc/sysinfo, the extended partition name
  and the partition UUID.

* New naming for PCI devices with system defined UIDs.

* The last few remaining alloc_bootmem calls are converted to memblock.

* The thread_info structure is stripped down and moved to the task_struct.
  The only field left in thread_info is the flags field.

* Rework of the arch topology code to fix a fake numa issue.

* Refactoring of the atomic primitives and add a new preempt_count
  implementation.

* Clocksource steering for the STP sync check offsets.

* The s390 specific headers are changed to make them usable with CLANG.

* Bug fixes and cleanup.

The shortlog:

Christian Borntraeger (1):
  s390/cpumf: Use configuration level indication for sampling data

Dan Carpenter (1):
  s390/crypto: unlock on error in prng_tdes_read()

Dong Jia Shi (1):
  s390/cio: clean up DEV_STATE_SENSE_PGID

Gerald Schaefer (1):
  s390/vmlogrdr: fix IUCV buffer allocation

Harald Freudenberger (1):
  MAINTAINERS: update for maintainer of s390/zcrypt

Heiko Carstens (24):
  s390: move thread_info into task_struct
  s390/uaccess: make setfs macro return void
  s390/thread_info: get rid of THREAD_ORDER define
  s390/cpumf: simplify psw generation
  s390: add cma support
  s390: update defconfig
  s390: convert remaining bootmem allocations to memblock
  s390: use generic asm-offsets.h
  s390/hypfs: add hypfs header file to uapi header export list
  s390/uapi: sort header export list
  s390/kexec: use node 0 when re-adding crash kernel memory
  s390/setup: fix memblock usage
  s390/numa: always use logical cpu and core ids
  s390/smp: use smp_get_base_cpu() helper function
  s390/topology: always use s390 specific sched_domain_topology_level
  s390/smp: initialize cpu_present_mask in setup_arch
  s390/topology: use cpu_topology array instead of per cpu variable
  s390/numa: establish cpu to node mapping early
  s390/numa: pin all possible cpus to nodes early
  s390: remove unused labels from entry.S
  s390: exclude early C code from gcov profiling
  s390: fix initrd corruptions with gcov/kcov instrumented kernels
  s390: cleanup arch/s390/kernel Makefile
  s390: provide memmove implementation

Jan Höppner (7):
  s390/dasd: Make setting queue_max_segments more explicit
  s390/dasd: Define often used variable
  s390/dasd: Replace simple_strtoul with kstrtouint
  s390/dasd: Make use of dasd_set_feature() more often
  s390/dasd: Eliminate race condition in dasd_generic_set_offline()
  s390/dasd: Fix locking issue when changing EER attribute
  s390/dasd: Fix locking issue when changing RO attribute

Lars-Peter Clausen (1):
  s390/zcrypt: Convert to PM ops

Martin Schwidefsky (12):
  s390/time: refactor clock sync
  s390/time: adjust last_update_clock at clock synchronization
  s390/time: steer clocksource on STP sync events
  s390/atomic: refactor atomic primitives
  s390/bitops: use atomic primitives for bitops
  s390/preempt: move preempt_count to the lowcore
  s390: move system_call field from thread_info to thread_struct
  s390: move cputime accounting fields from thread_info to thread_struct
  s390: move sys_call_table and last_break from thread_info to thread_struct
  s390/time: fix clocksource steering for negative clock offsets
  s390: fix kernel oops for CONFIG_MARCH_Z900=y builds
  s390: fix machine check panic stack switch

Masahiro Yamada (3):
  s390: delete unneeded #include  from facilities_src.h
  s390: squash facilities_src.h into gen_facilities.c
  s390: remove unneeded dependency for gen_facilities

Michael Holzheu (2):
  zcore: Improve startup-message text
  s390: Remove VLAIS in ptff() and clear_table()

Paul Gortmaker (9):
  s390: cio: make it explicitly non-modular
  s390: char: make zcore explicitly non-modular
  s390: char: make con3215 explicitly non-modular
  s390: char: make sclp_tty explicitly non-modular
  s390: char: make slcp_quiesce explicitly non-modular
  s390: hypfs: make inode explicitly non-modular
  s390: kernel: make lgr explicitly non-modular
  s390: hotplug: make pci_hpc explicitly non-modular
  s390: virtio: make ccw explicitly non-modular

Sebastian Ott (4):
  s390/pci: fix dma address calculation in map_sg
  s390/pci_dma: make lazy flush independent from the tlb_refresh bit
  s390/pci_dma: remove memset 

[GIT PULL] xen: features and fixes for 4.10 rc0

2016-12-12 Thread Juergen Gross
Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-4.10-rc0-tag

xen: features and fixes for 4.10 rc0

These are some fixes, a move of some arm related headers to share them
between arm and arm64 and a series introducing a helper to make code
more readable.

The most notable change is David stepping down as maintainer of the Xen
hypervisor interface. This results in me sending you the pull requests
for Xen related code from now on.

Thanks.

Juergen

 MAINTAINERS|   1 -
 arch/arm/include/asm/xen/hypercall.h   |  88 +
 arch/arm/include/asm/xen/hypervisor.h  |  40 +-
 arch/arm/include/asm/xen/interface.h   |  86 +
 arch/arm/include/asm/xen/page-coherent.h   |  99 +--
 arch/arm/include/asm/xen/page.h| 123 +-
 arch/arm/xen/enlighten.c   |   3 +-
 arch/arm64/include/asm/xen/hypercall.h |   2 +-
 arch/arm64/include/asm/xen/hypervisor.h|   2 +-
 arch/arm64/include/asm/xen/interface.h |   2 +-
 arch/arm64/include/asm/xen/page-coherent.h |   2 +-
 arch/arm64/include/asm/xen/page.h  |   2 +-
 arch/x86/include/asm/e820.h|  12 +-
 arch/x86/pci/xen.c |   4 +-
 arch/x86/xen/setup.c   |   6 +-
 drivers/block/xen-blkback/xenbus.c |  36 +++---
 drivers/block/xen-blkfront.c   |  81 
 drivers/char/tpm/xen-tpmfront.c|   8 +-
 drivers/input/misc/xen-kbdfront.c  |  13 +-
 drivers/net/xen-netback/xenbus.c   |  52 +++-
 drivers/net/xen-netfront.c |  67 +++---
 drivers/pci/xen-pcifront.c |   6 +-
 drivers/scsi/xen-scsifront.c   | 195
+
 drivers/video/fbdev/xen-fbfront.c  |  13 +-
 drivers/xen/balloon.c  |   6 +-
 drivers/xen/events/events_base.c   |   2 +-
 drivers/xen/gntalloc.c |   9 +-
 drivers/xen/gntdev.c   |   2 +-
 drivers/xen/platform-pci.c |   6 +-
 drivers/xen/xen-pciback/xenbus.c   |   8 +-
 drivers/xen/xenbus/xenbus_dev_frontend.c   |   2 +
 drivers/xen/xenbus/xenbus_probe.c  |   4 +-
 drivers/xen/xenbus/xenbus_probe_backend.c  |   8 +-
 drivers/xen/xenbus/xenbus_xs.c |  22 +++-
 fs/proc/generic.c  |   1 +
 fs/proc/internal.h |   1 -
 include/linux/proc_fs.h|   2 +
 include/xen/arm/hypercall.h|  87 +
 include/xen/arm/hypervisor.h   |  39 ++
 include/xen/arm/interface.h|  85 +
 include/xen/arm/page-coherent.h|  98 +++
 include/xen/arm/page.h | 122 ++
 include/xen/xenbus.h   |   4 +
 43 files changed, 670 insertions(+), 781 deletions(-)

Alex Thorlton (2):
  x86: Make E820_X_MAX unconditionally larger than E820MAX
  xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

Arnd Bergmann (1):
  xen-netback: fix error handling output

Boris Ostrovsky (1):
  xen/gntdev: Use VM_MIXEDMAP instead of VM_IO to avoid NUMA balancing

David Vrabel (2):
  MAINTAINERS: update XEN HYPERVISOR INTERFACE
  xenbus: fix deadlock on writes to /proc/xen/xenbus

Geliang Tang (1):
  xen-platform: use builtin_pci_driver

Juergen Gross (13):
  xen: introduce xenbus_read_unsigned()
  xen: make use of xenbus_read_unsigned() in xen-blkback
  xen: make use of xenbus_read_unsigned() in xen-blkfront
  xen: make use of xenbus_read_unsigned() in xen-tpmfront
  xen: make use of xenbus_read_unsigned() in xen-kbdfront
  xen: make use of xenbus_read_unsigned() in xen-netback
  xen: make use of xenbus_read_unsigned() in xen-netfront
  xen: make use of xenbus_read_unsigned() in xen-pcifront
  xen: make use of xenbus_read_unsigned() in xen-scsifront
  xen: make use of xenbus_read_unsigned() in xen-fbfront
  xen: make use of xenbus_read_unsigned() in xen-pciback
  xen: make use of xenbus_read_unsigned() in xenbus
  xen/scsifront: don't request a slot on the ring until request is ready

Julien Grall (1):
  arm/xen: Use alloc_percpu rather than __alloc_percpu

Konrad Rzeszutek Wilk (1):
  xen/pci: Bubble up error and fix description.

Marc Zyngier (1):
  arm/arm64: xen: Move shared architecture headers to include/xen/arm

Pan Bian (2):
  xen: set error code on failures
  xen: xenbus: set error code on failure

Quentin Lambert (1):
  xen-scsifront: Add a missing call to kfree

Ross Lagerwall (1):
  xen/balloon: Only mark a page as managed when it is released

Seth Forshee (1):
  xenfs: Use proc_create_mount_point() to create /proc/xen

Vitaly Kuznetsov (1):
  xen/events: use xen_vcpu_id mapping for 

Re: [PATCH 0/4] UEFI: EFI_MEMORY_ATTRIBUTES_TABLE support for x86

2016-12-12 Thread joeyli
Hi Sai,

On Wed, Dec 07, 2016 at 12:13:28PM -0800, Sai Praneeth Prakhya wrote:
> On Wed, 2016-12-07 at 20:04 +, Matt Fleming wrote:
> > On Wed, 07 Dec, at 11:01:06AM, Sai Praneeth Prakhya wrote:
> > > 
> > > Thanks Matt!
> > > 
> > > Would you like to see a new version of these patch series addressing
> > > your comments? Like
> > > 1. Dropping of patch #4
> > > 2. Adding Reviewed-by tag of Joey (Sorry for that)
> > > 3. This time with correct version number
> > 
> > No need, they're already in the 'next' branch of the EFI tree.
> 
> Great! Just saw the patches in 'next' branch.
> Thanks again Matt.
> 
> Regards,
> Sai
> 
>

Thanks for your patches to enable this function for x86.

Joey Lee 


Re: CVE-2016-7097 causes acl leak

2016-12-12 Thread Cong Wang
On Mon, Dec 12, 2016 at 4:26 PM, Mark Salyzyn  wrote:
>
> The leaks were introduced in 9p, gfs2, jfs and xfs drivers only.


Only the 9p case is obvious to me:

diff --git a/fs/9p/acl.c b/fs/9p/acl.c
index b3c2cc7..082d227 100644
--- a/fs/9p/acl.c
+++ b/fs/9p/acl.c
@@ -277,6 +277,7 @@ static int v9fs_xattr_set_acl(const struct
xattr_handler *handler,
case ACL_TYPE_ACCESS:
if (acl) {
struct iattr iattr;
+   struct posix_acl *old_acl = acl;

retval = posix_acl_update_mode(inode,
_mode, );
if (retval)
@@ -287,6 +288,7 @@ static int v9fs_xattr_set_acl(const struct
xattr_handler *handler,
 * by the mode bits. So don't
 * update ACL.
 */
+   posix_acl_release(old_acl);
value = NULL;
size = 0;
}


The rest are anti-pattern (modifying parameters on stack via address)
but look correct.


Re: [PATCH] SPCR: check bit width for the 16550 UART

2016-12-12 Thread Jon Masters
On 12/07/2016 10:23 AM, Mark Salter wrote:
> On Tue, 2016-12-06 at 01:34 -0500, Jon Masters wrote:
>> On 12/05/2016 10:55 PM, Duc Dang wrote:

>>> On Mon, Dec 5, 2016 at 6:27 PM, Jon Masters  wrote:

 HOWEVER while the console does come up, the use of "earlycon" on the
 command line (with no parameters) doesn't result in the early SPCR
 console coming up correctly. I see some garbled characters that
 suggest the baud (or register access width) is off somewhere.
>>> My bad that I did not catch this in the morning. Yes, earlycon does
>>> not seems to work as expected. I can see that earlycon parameters
>>> seems to be correct, but the bootconsole message does not come out
>>> (the following is from 'dmesg')
>>>
>>> [0.00] ACPI: SPCR: console: uart,mmio32,0x1c02,115200
>>> [0.00] earlycon: uart0 at MMIO32 0x1c02 (options 
>>> '115200')
>>> [0.00] bootconsole [uart0] enabled
>> The difference appears to be in the baud rate. When I explicitly specify
>> "earlycon=uart8250,mmio32,0x1c021000" no baud is set. When booting with
>> the SPCR, the baud is set to 9600 in my case or 115200 in yours. But we
>> both know that the base clock on the X-Gene UART is weird. Maybe
>> somehow we can explain this through the lack of setting a baud.
> 
> BTW, this behavior is same with devicetree.

At least it's consistent :)

> If you specify a baudrate with earlycon=, the driver tries to set that
> baudrate and if you have an 8250 with some non-standard baud clock, then
> it will fail. Perhaps SPCR shouldn't pass baud option to setup_earlycon().

Yet they seem to explicitly want to do this...in my conversations with some
others we agree that, in many cases, you really want to say "leave the baud
whatever the firmware set it", which would work in this case, but might
break some others. Then again, nobody on x86 Linux is really using the
SPCR today due to it not having been something they used until now and
due to the location of the COM ports being fairly well known ;)

So who knows what folks will prefer, but we should at least get the spec
to cover both situations by explicitly calling out Applied as special.

> Then again, setup_earlycon() has this comment:
> 
>  *setup_earlycon - match and register earlycon console
>  *@buf:   earlycon param string
>  *
>  *Registers the earlycon console matching the earlycon specified
>  *in the param string @buf. Acceptable param strings are of the form
>  *   ,io|mmio|mmio32|mmio32be,,
>  *   ,0x,
>  *   ,
>  *   
>  *
>  *Only for the third form does the earlycon setup() method receive the
>  * string in the 'options' parameter; all other forms set
>  *the parameter to NULL.
> 
> That part about the 3rd form doesn't seem to be true. I don't see where
> options gets set to NULL for forms other than the third.

I saw that also, and agree that it appears totally bogus. We'll want to get
the documentation fixed as part of this cleanup.

So I've been discussing some changes to the SPCR and the current proposal
is that we have two new subtypes - one for 16550s that are non-standard
register width/stride but use the typical base clock, and a specific
additional type for SBSA level 0 compatible 16550 UARTs (Applied). I
will followup when the specification document has been revised.

Jon.

P.S. I had a lot of fun over my birthday reading the original 8250 spec
and learning about how the DLAB stuff works (I think those brain cells had
died). Which - on a total tangent - finally helps with a long standing issue
we have had. We (a small cabal) have wanted to sneak in an instruction into
the ARM ISA or specs referring to DLAB (the initials of a certain person
who owns the ARM ARM) and now we will get to do this into the SBBR ;)

-- 
Computer Architect | Sent from my Fedora powered laptop



Re: [PATCH 4/5] firmware: add SmPL report for custom fallback mechanism

2016-12-12 Thread Julia Lawall


On Mon, 12 Dec 2016, Luis R. Rodriguez wrote:

> Even though most distributions today disable the fallback mechanism
> by default we've determined that we cannot remove them from the kernel.
> This is not well understood so document the reason and logic behind that.
>
> Recent discussions suggest some future userspace development prospects which
> may enable fallback mechanisms to become more useful while avoiding some
> historical issues. These discussions have made it clear though that there
> is less value to the custom fallback mechanism and an alternative can be
> provided in the future. Its also clear that some old users of the custom
> fallback mechanism were using it as a copy and paste error. Because of
> all this add a Coccinelle SmPL patch to help maintainers police for new
> incorrect users of the custom fallback mechanism.
>
> Best we can do for now then is police for new users of the custom
> fallback mechanism and and fix incorrect users when they are spotted.
> Drivers can only be transitioned out of the custom fallback mechanism
> once we know old userspace cannot be not be broken by a kernel change.
>
> The current SmPL patch reports:
>
> $ export COCCI=scripts/coccinelle/api/request_firmware-custom-fallback.cocci
> $ make coccicheck MODE=report
>
> drivers/leds/leds-lp55xx-common.c:227:8-31: WARNING: please check if driver 
> really needs a custom fallback mechanism
> drivers/firmware/dell_rbu.c:622:17-40: WARNING: please check if driver really 
> needs a custom fallback mechanism
>
> Cc: Richard Purdie 
> Cc: Jacek Anaszewski 
> Cc: linux-l...@vger.kernel.org
> Cc: Abhay Salunke 
> Signed-off-by: Luis R. Rodriguez 

Acked-by: julia.law...@lip6.fr


> ---
>  .../driver-api/firmware/fallback-mechanisms.rst| 17 ++
>  .../api/request_firmware-custom-fallback.cocci | 37 
> ++
>  2 files changed, 54 insertions(+)
>  create mode 100644 
> scripts/coccinelle/api/request_firmware-custom-fallback.cocci
>
> diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst 
> b/Documentation/driver-api/firmware/fallback-mechanisms.rst
> index edce1d76ce29..955c11d6ff9d 100644
> --- a/Documentation/driver-api/firmware/fallback-mechanisms.rst
> +++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst
> @@ -28,6 +28,12 @@ CONFIG_FW_LOADER_USER_HELPER_FALLBACK=n
>  the kobject uevent fallback mechanism will never take effect even
>  for request_firmware_nowait() when uevent is set to true.
>
> +Although the fallback mechanisms are not used widely today they cannot be
> +removed from the kernel since some old userspace may exist which could
> +entirely depend on the fallback mechanism enabled with the kernel config 
> option
> +CONFIG_FW_LOADER_USER_HELPER_FALLBACK. In the future though drivers may opt
> +to embrace a different API which provides alternative fallback mechanisms.
> +
>  Justifying the firmware fallback mechanism
>  ==
>
> @@ -176,6 +182,17 @@ but you want to suppress kobject uevents, as you have a 
> custom solution which
>  will monitor for your device addition into the device hierarchy somehow and
>  load firmware for you through a custom path.
>
> +The custom fallback mechanism can often be enabled by mistake. We currently
> +have only 2 users of it, and little justification to enable it for other 
> users.
> +Since it is a common driver developer mistake to enable it, help police for
> +new users of the custom fallback mechanism with::
> +
> +$ export 
> COCCI=scripts/coccinelle/api/request_firmware-avoid-init-probe-init.cocci
> +$ make coccicheck MODE=report
> +
> +Drivers can only be transitioned out of the custom fallback mechanism
> +once we know old userspace cannot be not be broken by a kernel change.
> +
>  Firmware fallback timeout
>  =
>
> diff --git a/scripts/coccinelle/api/request_firmware-custom-fallback.cocci 
> b/scripts/coccinelle/api/request_firmware-custom-fallback.cocci
> new file mode 100644
> index ..c7598cfc4780
> --- /dev/null
> +++ b/scripts/coccinelle/api/request_firmware-custom-fallback.cocci
> @@ -0,0 +1,37 @@
> +// Avoid the firmware custom fallback mechanism at all costs
> +//
> +// request_firmware_nowait() API enables explicit request for use of the 
> custom
> +// fallback mechanism if firmware is not found. Chances are high its use is
> +// just a copy and paste bug. Before you fix the driver be sure to *verify* 
> no
> +// custom firmware loading tool exists that would otherwise break if we 
> replace
> +// the driver to use the uevent fallback mechanism.
> +//
> +// Confidence: High
> +//
> +// Reason for low confidence:
> +//
> +// Copyright: (C) 2016 Luis R. Rodriguez  GPLv2.
> +//
> +// Options: --include-headers
> +
> +virtual report
> +virtual context
> +
> +@ r1 depends on report || context @
> 

Re: [PATCH v3 1/4] pinctrl: aspeed: Read and write bits in LPC and GFX controllers

2016-12-12 Thread Andrew Jeffery
On Mon, 2016-12-12 at 10:27 -0600, Rob Herring wrote:
> On Tue, Dec 06, 2016 at 02:11:49PM +1100, Andrew Jeffery wrote:
> > The System Control Unit IP block in the Aspeed SoCs is typically where
> > the pinmux configuration is found, but not always. A number of pins
> > depend on state in one of LPC Host Control (LHC) or SoC Display
> > Controller (GFX) IP blocks, so the Aspeed pinmux drivers should have the
> > means to adjust these as necessary.
> > 
> > We use syscon to cast a regmap over the GFX and LPC blocks, which is
> > used as an arbitration layer between the relevant driver and the pinctrl
> > subsystem. The regmaps are then exposed to the SoC-specific pinctrl
> > drivers by phandles in the devicetree, and are selected during a mux
> > request by querying a new 'ip' member in struct aspeed_sig_desc.
> > 
> > > > Signed-off-by: Andrew Jeffery 
> > ---
> >  .../devicetree/bindings/pinctrl/pinctrl-aspeed.txt |  50 ++-
> >  drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c |  18 +--
> >  drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c |  48 --
> >  drivers/pinctrl/aspeed/pinctrl-aspeed.c| 161 
> > +
> >  drivers/pinctrl/aspeed/pinctrl-aspeed.h|  32 ++--
> >  5 files changed, 214 insertions(+), 95 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt 
> > b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
> > index 2ad18c4ea55c..115b0cce6c1c 100644
> > --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
> > +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
> > @@ -4,12 +4,19 @@ Aspeed Pin Controllers
> >  The Aspeed SoCs vary in functionality inside a generation but have a 
> > common mux
> >  device register layout.
> >  
> > -Required properties:
> > -- compatible : Should be any one of the following:
> > > > -   "aspeed,ast2400-pinctrl"
> > > > -   "aspeed,g4-pinctrl"
> > > > -   "aspeed,ast2500-pinctrl"
> > > > -   "aspeed,g5-pinctrl"
> > +Required properties for g4:
> > > > +- compatible : Should be any one of the 
> > > > following:
> > > > +   "aspeed,ast2400-pinctrl"
> > > > +   "aspeed,g4-pinctrl"
> > +
> > +Required properties for g5:
> > > > +- compatible : Should be any one of the 
> > > > following:
> > > > +   "aspeed,ast2500-pinctrl"
> > > > +   "aspeed,g5-pinctrl"
> > +
> > > > +- aspeed,external-nodes:   A cell of phandles to external 
> > > > controller nodes:
> > > > +   0: compatible with 
> > > > "aspeed,ast2500-gfx", "syscon"
> > > > +   1: compatible with 
> > > > "aspeed,ast2500-lpchc", "syscon"
> >  
> >  The pin controller node should be a child of a syscon node with the 
> > required
> >  property:
> > @@ -47,7 +54,7 @@ RGMII1 RGMII2 RMII1 RMII2 SD1 SPI1 SPI1DEBUG SPI1PASSTHRU 
> > TIMER4 TIMER5 TIMER6
> >  TIMER7 TIMER8 VGABIOSROM
> >  
> >  
> > -Examples:
> > +g4 Example:
> >  
> > > >  syscon: scu@1e6e2000 {
> > > >     compatible = "syscon", "simple-mfd";
> > > > @@ -63,5 +70,34 @@ syscon: scu@1e6e2000 {
> > > >     };
> >  };
> >  
> > +g5 Example:
> > +
> > +apb {
> > > > > > +   gfx: display@1e6e6000 {
> > > > +   compatible = "aspeed,ast2500-gfx", "syscon";
> > > > +   reg = <0x1e6e6000 0x1000>;
> > > > +   };
> > +
> > > > > > +   lpchc: lpchc@1e7890a0 {
> > > > +   compatible = "aspeed,ast2500-lpchc", "syscon";
> > > > +   reg = <0x1e7890a0 0xc4>;
> > > > +   };
> > +
> > > > > > +   syscon: scu@1e6e2000 {
> > +   compatible = "syscon", "simple-mfd";
> 
> I must have missed this the first time, but "syscon" should be used with 
> a specific compatible. Though, the scu binding does define one.

Yes, the example should be fixed.

> 
> > > > +   reg = <0x1e6e2000 0x1a8>;
> > +
> > +   pinctrl: pinctrl {
> 
> Is this the only child? 

No. A incomplete list of other functions in the SCU includes:

* An RNG
* Power management
* PCI configuration
* System reset
* Clock configuration

> 
> > +   compatible = "aspeed,g5-pinctrl";
> 
> There's no register range for pinctrl?

This may be a mistake on my part; when I wrote this I had no experience
with writing devicetree bindings (and still don't have a lot).

The SCU does have register regions for pinctrl but on reflection I feel
neither the mfd nor syscon bindings describe how children's resources
should be treated in general. The example in the mfd bindings is for
hardware that is register-bit-led,compatible, whose bindings use the
'offset' property rather than 'reg', which still describes where, but
not using the reg property. Given my uncertainty with reg in an mfd
child, I wrote the 

linux-next: Tree for Dec 13

2016-12-12 Thread Stephen Rothwell
Hi all,

Please do not add any material for v4.11 to your linux-next included
branches until after v4.10-rc1 has been released.

Changes since 20161212:

The hid tree lost its build failure.

The spi tree lost its build failure.

Non-merge commits (relative to Linus' tree): 8829
 7664 files changed, 471419 insertions(+), 200537 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (df5f0f0a028c Merge branch 'ras-core-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (152b695d7437 builddeb: fix cross-building to 
arm64 producing host-arch debs)
Merging arc-current/for-curr (7badf6fefca8 ARC: axs10x: really enable ARC PGU)
Merging arm-current/fixes (8478132a8784 Revert "arm: move exports to 
definitions")
Merging m68k-current/for-linus (7e251bb21ae0 m68k: Fix ndelay() macro)
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (dadc4a1bb9f0 powerpc/64: Fix placement of .text to 
be immediately following .head.text)
Merging sparc/master (8fa3b6f9392b Merge tag 'cris-for-4.10' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jesper/cris)
Merging net/master (8fa3b6f9392b Merge tag 'cris-for-4.10' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jesper/cris)
Merging ipsec/master (bc3913a5378c Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging netfilter/master (045169816b31 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging ipvs/master (045169816b31 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging wireless-drivers/master (fcd2042e8d36 mwifiex: printk() overflow with 
32-byte SSIDs)
Merging mac80211/master (9590112241ba tipc: fix link statistics counter errors)
Merging sound-current/for-linus (995c6a7fd9b9 ALSA: hiface: Fix M2Tech hiFace 
driver sampling rate change)
Merging pci-current/for-linus (e42010d8207f PCI: Set Read Completion Boundary 
to 128 iff Root Port supports it (_HPX))
Merging driver-core.current/driver-core-linus (a25f0944ba9b Linux 4.9-rc5)
Merging tty.current/tty-linus (a909d3e63699 Linux 4.9-rc3)
Merging usb.current/usb-linus (e5517c2a5a49 Linux 4.9-rc7)
Merging usb-gadget-fixes/fixes (05e78c6933d6 usb: gadget: f_fs: fix wrong 
parenthesis in ffs_func_req_match())
Merging usb-serial-fixes/usb-linus (46490c347df4 USB: serial: option: add dlink 
dwm-158)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (4320f9d4c183 phy: sun4i: check PMU presence when poking 
unknown bit of pmu)
Merging staging.current/staging-linus (a25f0944ba9b Linux 4.9-rc5)
Merging char-misc.current/char-misc-linus (a25f0944ba9b Linux 4.9-rc5)
Merging input-current/for-linus (2425f1808123 Input: change KEY_DATA from 0x275 
to 0x277)
Merging crypto-current/master (678b5c6b22fe crypto: algif_aead - fix 
uninitialized variable warning)
Merging ide/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/use

[PATCH v2] btrfs: limit async_work allocation and worker func duration

2016-12-12 Thread Maxim Patlasov
Problem statement: unprivileged user who has read-write access to more than
one btrfs subvolume may easily consume all kernel memory (eventually
triggering oom-killer).

Reproducer (./mkrmdir below essentially loops over mkdir/rmdir):

[root@kteam1 ~]# cat prep.sh

DEV=/dev/sdb
mkfs.btrfs -f $DEV
mount $DEV /mnt
for i in `seq 1 16`
do
mkdir /mnt/$i
btrfs subvolume create /mnt/SV_$i
ID=`btrfs subvolume list /mnt |grep "SV_$i$" |cut -d ' ' -f 2`
mount -t btrfs -o subvolid=$ID $DEV /mnt/$i
chmod a+rwx /mnt/$i
done

[root@kteam1 ~]# sh prep.sh

[maxim@kteam1 ~]$ for i in `seq 1 16`; do ./mkrmdir /mnt/$i 2000 2000 & done

[root@kteam1 ~]# for i in `seq 1 4`; do grep "kmalloc-128" /proc/slabinfo | 
grep -v dma; sleep 60; done
kmalloc-12810144  10144128   321 : tunables000 : 
slabdata317317  0
kmalloc-128   9992352 9992352128   321 : tunables000 : 
slabdata 312261 312261  0
kmalloc-128   24226752 24226752128   321 : tunables000 
: slabdata 757086 757086  0
kmalloc-128   42754240 42754240128   321 : tunables000 
: slabdata 1336070 1336070  0

The huge numbers above come from insane number of async_work-s allocated
and queued by btrfs_wq_run_delayed_node.

The problem is caused by btrfs_wq_run_delayed_node() queuing more and more
works if the number of delayed items is above BTRFS_DELAYED_BACKGROUND. The
worker func (btrfs_async_run_delayed_root) processes at least
BTRFS_DELAYED_BATCH items (if they are present in the list). So, the machinery
works as expected while the list is almost empty. As soon as it is getting
bigger, worker func starts to process more than one item at a time, it takes
longer, and the chances to have async_works queued more than needed is getting
higher.

The problem above is worsened by another flaw of delayed-inode implementation:
if async_work was queued in a throttling branch (number of items >=
BTRFS_DELAYED_WRITEBACK), corresponding worker func won't quit until
the number of items < BTRFS_DELAYED_BACKGROUND / 2. So, it is possible that
the func occupies CPU infinitely (up to 30sec in my experiments): while the
func is trying to drain the list, the user activity may add more and more
items to the list.

The patch fixes both problems in straightforward way: refuse queuing too
many works in btrfs_wq_run_delayed_node and bail out of worker func if
at least BTRFS_DELAYED_WRITEBACK items are processed.

Changed in v2: remove support of thresh == NO_THRESHOLD.

Signed-off-by: Maxim Patlasov 
---
 fs/btrfs/async-thread.c  |   14 ++
 fs/btrfs/async-thread.h  |1 +
 fs/btrfs/delayed-inode.c |6 --
 3 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/async-thread.c b/fs/btrfs/async-thread.c
index e0f071f..63d1977 100644
--- a/fs/btrfs/async-thread.c
+++ b/fs/btrfs/async-thread.c
@@ -86,6 +86,20 @@ btrfs_work_owner(struct btrfs_work *work)
return work->wq->fs_info;
 }
 
+bool btrfs_workqueue_normal_congested(struct btrfs_workqueue *wq)
+{
+   /*
+* We could compare wq->normal->pending with num_online_cpus()
+* to support "thresh == NO_THRESHOLD" case, but it requires
+* moving up atomic_inc/dec in thresh_queue/exec_hook. Let's
+* postpone it until someone needs the support of that case.
+*/
+   if (wq->normal->thresh == NO_THRESHOLD)
+   return false;
+
+   return atomic_read(>normal->pending) > wq->normal->thresh * 2;
+}
+
 BTRFS_WORK_HELPER(worker_helper);
 BTRFS_WORK_HELPER(delalloc_helper);
 BTRFS_WORK_HELPER(flush_delalloc_helper);
diff --git a/fs/btrfs/async-thread.h b/fs/btrfs/async-thread.h
index 8e52484..1f95973 100644
--- a/fs/btrfs/async-thread.h
+++ b/fs/btrfs/async-thread.h
@@ -84,4 +84,5 @@ void btrfs_workqueue_set_max(struct btrfs_workqueue *wq, int 
max);
 void btrfs_set_work_high_priority(struct btrfs_work *work);
 struct btrfs_fs_info *btrfs_work_owner(struct btrfs_work *work);
 struct btrfs_fs_info *btrfs_workqueue_owner(struct __btrfs_workqueue *wq);
+bool btrfs_workqueue_normal_congested(struct btrfs_workqueue *wq);
 #endif
diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c
index 3eeb9cd..de946dd 100644
--- a/fs/btrfs/delayed-inode.c
+++ b/fs/btrfs/delayed-inode.c
@@ -1356,7 +1356,8 @@ release_path:
total_done++;
 
btrfs_release_prepared_delayed_node(delayed_node);
-   if (async_work->nr == 0 || total_done < async_work->nr)
+   if ((async_work->nr == 0 && total_done < BTRFS_DELAYED_WRITEBACK) ||
+   total_done < async_work->nr)
goto again;
 
 free_path:
@@ -1372,7 +1373,8 @@ static int btrfs_wq_run_delayed_node(struct 
btrfs_delayed_root *delayed_root,
 {
struct btrfs_async_delayed_work *async_work;
 
-   if (atomic_read(_root->items) < BTRFS_DELAYED_BACKGROUND)
+   if (atomic_read(_root->items) < 

[PATCH v2] kasan: Support for r/w instrumentation control

2016-12-12 Thread Maninder Singh
This provide option to control sanity of read and write operations
Both read and write instrumentation increase size of uImage, So using
this option read or write instrumentation can be avoided if not required.
Useful in case of module sanity, using this uImage sanity can be avoided.

Also user space ASAN provides this support for read/write instrumentation
control.

Signed-off-by: Vaneet narang 
Signed-off-by: Maninder Singh 
Reviewed-by: Ajeet Yadav 
---
v1 -> v2: Added Documentation for the same.

 Documentation/dev-tools/kasan.rst | 16 
 lib/Kconfig.kasan | 16 
 scripts/Makefile.kasan|  4 
 3 files changed, 36 insertions(+)

diff --git a/Documentation/dev-tools/kasan.rst 
b/Documentation/dev-tools/kasan.rst
index f7a18f2..b8147df 100644
--- a/Documentation/dev-tools/kasan.rst
+++ b/Documentation/dev-tools/kasan.rst
@@ -40,6 +40,22 @@ similar to the following to the respective kernel Makefile:
 
 KASAN_SANITIZE := n
 
+Control Over Read/Write Instrumentation of kernel::
+
+- To Disable Read Instrumentation of kernel with:
+
+CONFIG_KASAN_READS = n
+
+Because in some cases we need to check only memory write sanitization
+for better performance, read instrumentation can be disabled.
+
+- To Disable Write Instrumentation of kernel with:
+
+CONFIG_KASAN_WRITES = n
+
+In case when to instrument only external modules, not the entire kernel
+for read or write intrumentation or both.
+
 Error reports
 ~
 
diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
index bd38aab..37d1de9 100644
--- a/lib/Kconfig.kasan
+++ b/lib/Kconfig.kasan
@@ -45,6 +45,22 @@ config KASAN_INLINE
 
 endchoice
 
+config KASAN_READS
+   prompt "Read instrumentation"
+   bool
+   default y
+   depends on KASAN
+   help
+ This configuration controls the sanity of memory read.
+
+config KASAN_WRITES
+   prompt "Write instrumentation"
+   bool
+   default y
+   depends on KASAN
+   help
+ This configuration controls the sanity of memory write.
+
 config TEST_KASAN
tristate "Module for testing kasan for bug detection"
depends on m && KASAN
diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan
index 37323b0..a61b18e 100644
--- a/scripts/Makefile.kasan
+++ b/scripts/Makefile.kasan
@@ -29,3 +29,7 @@ else
 endif
 endif
 endif
+
+CFLAGS_KASAN += $(call cc-option, \
+   $(if $(CONFIG_KASAN_READS),, --param asan-instrument-reads=0) \
+   $(if $(CONFIG_KASAN_WRITES),, --param asan-instrument-writes=0))
-- 
1.9.1



Re: [PATCH] Input: ar1021-i2c - fix too long name in driver's device table

2016-12-12 Thread Wolfram Sang
On Mon, Dec 12, 2016 at 03:57:02PM -0800, Dmitry Torokhov wrote:
> The name field in structure i2c_device_id is 20 characters, and we
> expect it to be NULL-terminated, however we are trying to stuff it with
> 21 bytes and thus NULL-terminator is lost. This causes issues when one
> creates device with name "MICROCHIP_AR1021_I2C" as i2c core cuts off the
> last "C", and automatic module loading by alias does not work as result.
> 
> The -I2C suffix in the device name is superfluous, we know what bus we
> are dealing with, so let's drop it.
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116211
> Signed-off-by: Dmitry Torokhov 

Acked-by: Wolfram Sang 



signature.asc
Description: PGP signature


[GIT PULL] Thermal management updates for v4.10-rc1

2016-12-12 Thread Zhang Rui
Hi, Linus,

Please pull from
  git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next

to receive the latest Thermal Management updates for v4.10-rc1 with
top-most commit 0faf7dd5a947006978b549dfe29a01b710becf4a:

  MAINTAINERS: Samsung: Update maintainer for PWM FAN and SAMSUNG
THERMAL (2016-12-13 11:20:23 +0800)

on top of commit 23400ac997062647f2b63c82030d189671b1effe:

  Merge branch 'for-rc' of
git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux (2016-11-22
13:53:01 -0800)

Specifics:

- Thermal core code reorganization and cleanup. Two new files are
  created for thermal sysfs I/F code and thermal helper functions.
  From: Eduardo Valentin.

- Sanitize hotplug and locking for x86_pkg_temp driver.
  From: Thomas Gleixner.

- Update MAINTAINER file for pwm-fan driver and Samsung thermal driver.
  From: Lukasz Majewski.

- Fix module auto-load for max77620, tango and db8500 thermal driver.
  From: Javier Martinez Canillas.

- Fix a bug that thermal hwmon sysfs I/F returns wrong critical trip
  point temperature value. From: Krzysztof Kozlowski.

- Add Skylake PCH 100 series support for intel_pch_thermal driver.
  From: OGAWA Hirofumi.

- Small fixes and cleanups for platform thermal drivers.
  From Julia Lawall, Luis Henriques, Leo Yan, Stephen Boyd,
  Shawn Lin, Javi Merino and Lukasz Luba.

thanks,
rui


Eduardo Valentin (49):
  thermal: core: prevent zones with no types to be registered
  thermal: core: group thermal_zone DEVICE_ATTR's declarations
  thermal: core: group device_create_file() calls that are always
created
  thermal: core: use dev.groups to manage always present tz
attributes
  thermal: core: move emul_temp creation to tz->device.groups
  thermal: core: move mode attribute to tz->device.groups
  thermal: core: move passive attr to tz->device.groups
  thermal: core: improve power actor documentation
  thermal: core: move power actor code out of sysfs I/F section
  thermal: core: remove useless empty line
  thermal: core: fix style on remove_trip_attrs()
  thermal: core: move the trip attrs to the tz sysfs I/F section
  thermal: core: create tz->device.groups dynamically
  thermal: core: move trips attributes to tz->device.groups
  thermal: core: remove unnecessary device_remove() calls
  thermal: core: split passive_store
  thermal: core: split policy_store
  thermal: core: split available_policies_show()
  thermal: core: move to_thermal_zone() macro to header file
  thermal: core: treat correctly the return value of *scanf calls
  thermal: core: match parenthesis on code alignment
  thermal: core: move thermal_zone sysfs to thermal_sysfs.c
  thermal: core: move to_cooling_device macro to header file
  thermal: core: move cooling device sysfs to thermal_sysfs.c
  thermal: core: remove a couple of style issues on helpers
  thermal: core: introduce thermal_helpers.c
  thermal: core: group functions related to governor handling
  thermal: core: move idr handling to device management section
  thermal: core: small style fix on __unbind() helper
  thermal: core: move __unbind() helper to where it is used
  thermal: core: move bind_cdev() to where it is used
  thermal: core: move bind_tz() to where it is used
  thermal: core: fix couple of style issues on __bind() helper
  thermal: core: move __bind() to where it is used
  thermal: core: add inline to print_bind_err_msg()
  thermal: core: move notify to the zone update section
  thermal: core: add a comment describing the main update loop
  thermal: core: add a comment describing the power actor section
  thermal: core: add a comment describing the device management
section
  thermal: sysfs: remove symbols of emul_temp when config is
disabled
  thermal: core: remove FSF address in the GPL notice
  thermal: core: small style fix when checking for
__find_governor()
  thermal: core: standardize line breaking alignment
  thermal: core: remove void function return statements
  thermal: core: remove style warnings and checks
  thermal: core: improve kerneldoc entry of
thermal_cooling_device_unregister
  thermal: core: use kzalloc(sizeof(*ptr),...)
  thermal: sysfs: use kcalloc() instead of kzalloc()
  thermal: core: move slop and offset helpers to thermal_helpers.c

Javi Merino (1):
  devfreq_cooling: pass a pointer to devfreq in the power model
callbacks

Javier Martinez Canillas (3):
  thermal: max77620: Fix module autoload
  thermal: tango: Fix module autoload
  thermal: db8500: Fix module autoload

Julia Lawall (2):
  thermal: hwmon: use permission-specific DEVICE_ATTR variants
  thermal: int340x_thermal: use permission-specific DEVICE_ATTR
variants

Krzysztof Kozlowski (1):
  thermal: hwmon: Properly report critical temperature in sysfs


[PATCH RFC] [media] m5mols: add missing dependency on VIDEO_IR_I2C

2016-12-12 Thread Nicholas Mc Guire
The Depends on: tag in Kconfig for CONFIG_VIDEO_M5MOLS does not list
VIDEO_IR_I2C so Kconfig displays the dependencies needed so the M-5MOLS
driver can not be found. 

Fixes: commit cb7a01ac324b ("[media] move i2c files into drivers/media/i2c")
Signed-off-by: Nicholas Mc Guire <hof...@osadl.org>
---

searching for VIDEO_M5MOLS in menuconfig currently shows the following 
dependencies
 Depends on: MEDIA_SUPPORT [=m] && I2C [=y] && VIDEO_V4L2 [=m] && \
 VIDEO_V4L2_SUBDEV_API [=y] && MEDIA_CAMERA_SUPPORT [=y]  
but as the default settings include MEDIA_SUBDRV_AUTOSELECT=y the
"I2C module for IR" submenu (CONFIG_VIDEO_IR_I2C) is not displayed
adding the VIDEO_IR_I2C to the dependency list makes this clear

Q: should a patch like this carry a Fixes: tag ? 

Patch was tested against: x86_64_defconfig

Patch is against 4.9.0 (localversion-next is next-20161212)

 drivers/media/i2c/m5mols/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/m5mols/Kconfig b/drivers/media/i2c/m5mols/Kconfig
index dc8c250..6847a1b 100644
--- a/drivers/media/i2c/m5mols/Kconfig
+++ b/drivers/media/i2c/m5mols/Kconfig
@@ -1,6 +1,6 @@
 config VIDEO_M5MOLS
tristate "Fujitsu M-5MOLS 8MP sensor support"
-   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   depends on I2C && VIDEO_IR_I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
depends on MEDIA_CAMERA_SUPPORT
---help---
  This driver supports Fujitsu M-5MOLS camera sensor with ISP
-- 
2.1.4



DO YOU NEED A LOAN??

2016-12-12 Thread bancoleite
Are you in need of a loan? Apply for more details.


[PATCH] [media] m5mols: set usleep_range delta greater 0

2016-12-12 Thread Nicholas Mc Guire
This delay is in non-atomic context and it does not seem to be
time-critical so relax it to allow the timer subsystem to optimize
hrtimers. 

Signed-off-by: Nicholas Mc Guire <hof...@osadl.org>
---
problem was located by coccinelle spatch

The problem is that usleep_range is calculating the delay by
 exp = ktime_add_us(ktime_get(), min)
 delta = (u64)(max - min) * NSEC_PER_USEC
so delta is set to 0
and then calls
  schedule_hrtimeout_range(exp, 0,...)
effectively this means that the clock subsystem has no room to
optimize which makes little sense as this is not atomic context
anyway so there is not guarantee of precision here.

As this is not a critical delay and the jitter of any system is
in the 10s of microseconds range anyway the range is set to 200
to 300 microseconds - this change cold have a negligible impact
on bandwidth (though I doubt this is relevant or even measurable
here) thus it needs a review by someone that knows the details
of the device and preferably would increase that range.

A comment in the second case was added to clarify the intent of
the delay as time between i2c transfers.

Patch was only compile tested against: x86_64_defconfig + CONFIG_MEDIA_SUPPORT=m
MEDIA_CAMERA_SUPPORT=y, VIDEO_V4L2_SUBDEV_API, MEDIA_DIGITAL_TV-_SUPPORT=y
MEDIA_RC_SUPPORT=y, MEDIA_CONTROLLER=y, VIDEO_V4L2_SUBDEV_API=y
MEDIA_SUBDRV_AUTOSELECT=n, CONFIG_VIDEO_M5MOLS=m

Patch is against 4.9.0 (localversion-next is next-20161212)

 drivers/media/i2c/m5mols/m5mols_core.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/m5mols/m5mols_core.c 
b/drivers/media/i2c/m5mols/m5mols_core.c
index acb804b..23e8616 100644
--- a/drivers/media/i2c/m5mols/m5mols_core.c
+++ b/drivers/media/i2c/m5mols/m5mols_core.c
@@ -168,7 +168,7 @@ static int m5mols_read(struct v4l2_subdev *sd, u32 size, 
u32 reg, u32 *val)
msg[1].buf = rbuf;
 
/* minimum stabilization time */
-   usleep_range(200, 200);
+   usleep_range(200, 300);
 
ret = i2c_transfer(client->adapter, msg, 2);
 
@@ -268,7 +268,8 @@ int m5mols_write(struct v4l2_subdev *sd, u32 reg, u32 val)
 
*buf = m5mols_swap_byte((u8 *), size);
 
-   usleep_range(200, 200);
+   /* minimum stabilization time */
+   usleep_range(200, 300);
 
ret = i2c_transfer(client->adapter, msg, 1);
if (ret == 1)
-- 
2.1.4



Re: [PATCH v2] audit: use proper refcount locking on audit_sock

2016-12-12 Thread Richard Guy Briggs
On 2016-12-12 15:18, Paul Moore wrote:
> On Mon, Dec 12, 2016 at 5:03 AM, Richard Guy Briggs  wrote:
> > Resetting audit_sock appears to be racy.
> >
> > audit_sock was being copied and dereferenced without using a refcount on
> > the source sock.
> >
> > Bump the refcount on the underlying sock when we store a refrence in
> > audit_sock and release it when we reset audit_sock.  audit_sock
> > modification needs the audit_cmd_mutex.
> >
> > See: https://lkml.org/lkml/2016/11/26/232
> >
> > Thanks to Eric Dumazet  and Cong Wang
> >  on ideas how to fix it.
> >
> > Signed-off-by: Richard Guy Briggs 
> > ---
> > There has been a lot of change in the audit code that is about to go
> > upstream to address audit queue issues.  This patch is based on the
> > source tree: git://git.infradead.org/users/pcmoore/audit#next
> > ---
> >  kernel/audit.c |   34 --
> >  1 files changed, 28 insertions(+), 6 deletions(-)
> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index f20eee0..439f7f3 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -452,7 +452,9 @@ static void auditd_reset(void)
> > struct sk_buff *skb;
> >
> > /* break the connection */
> > +   sock_put(audit_sock);
> > audit_pid = 0;
> > +   audit_nlk_portid = 0;
> > audit_sock = NULL;
> >
> > /* flush all of the retry queue to the hold queue */
> > @@ -478,6 +480,12 @@ static int kauditd_send_unicast_skb(struct sk_buff 
> > *skb)
> > if (rc >= 0) {
> > consume_skb(skb);
> > rc = 0;
> > +   } else {
> > +   if (rc & (-ENOMEM|-EPERM|-ECONNREFUSED)) {
> 
> I dislike the way you wrote this because instead of simply looking at
> this to see if it correct I need to sort out all the bits and find out
> if there are other error codes that could run afoul of this check ...
> make it simple, e.g. (rc == -ENOMEM || rc == -EPERM || ...).
> Actually, since EPERM is 1, -EPERM (-1 in two's compliment is
> 0x) is going to cause this to be true for pretty much any
> value of rc, yes?

Yes, you are correct.  We need there a logical or on the results of each
comparison to the return code rather than bit-wise or-ing the result
codes together first to save a step.

> > +   mutex_lock(_cmd_mutex);
> > +   auditd_reset();
> > +   mutex_unlock(_cmd_mutex);
> > +   }
> 
> The code in audit#next handles netlink_unicast() errors in
> kauditd_thread() and you are adding error handling code here in
> kauditd_send_unicast_skb() ... that's messy.  I don't care too much
> where the auditd_reset() call is made, but let's only do it in one
> function; FWIW, I originally put the error handling code in
> kauditd_thread() because there was other error handling code that
> needed to done in that scope so it resulted in cleaner code.

Hmmm, I seem to remember it not returning the return code and I thought
I had changed it to do so, but I see now that it was already there.
Agreed, I needlessly duplicated that error handling.

> Related, I see you are now considering ENOMEM to be a fatal condition,
> that differs from the AUDITD_BAD macro in kauditd_thread(); this
> difference needs to be reconciled.

Also correct about -EPERM now that I check back to the intent of commit
32a1dbaece7e ("audit: try harder to send to auditd upon netlink
failure")

> Finally, you should update the comment header block for auditd_reset()
> that it needs to be called with the audit_cmd_mutex held.

Yup.

> > @@ -1004,17 +1018,22 @@ static int audit_receive_msg(struct sk_buff *skb, 
> > struct nlmsghdr *nlh)
> > return -EACCES;
> > }
> > if (audit_pid && new_pid &&
> > -   audit_replace(requesting_pid) != -ECONNREFUSED) 
> > {
> > +   (audit_replace(requesting_pid) & 
> > (-ECONNREFUSED|-EPERM|-ENOMEM))) {
> 
> Do we simply want to treat any error here as fatal, and not just
> ECONN/EPERM/ENOMEM?  If not, let's come up with a single macro to
> handle the fatal netlink_unicast() return codes so we have some chance
> to keep things consistent in the future.

I'll work through this before I post another patch...

> paul moore

- RGB

--
Richard Guy Briggs 
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635


Re: [PATCH v3 6/6] mfd: dt: Move syscon bindings to syscon subdirectory

2016-12-12 Thread Andrew Jeffery
On Mon, 2016-12-12 at 09:39 -0600, Rob Herring wrote:
> On Tue, Dec 06, 2016 at 01:53:21PM +1100, Andrew Jeffery wrote:
> > The use of syscons is growing, lets collate them in their own part of
> > the bindings tree.
> > 
> > > > Signed-off-by: Andrew Jeffery 
> > ---
> >  Documentation/devicetree/bindings/mfd/{ => syscon}/aspeed-scu.txt 
> > | 0
> >  Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-gpbr.txt 
> > | 0
> >  Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-matrix.txt   
> > | 0
> >  Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-smc.txt  
> > | 0
> >  Documentation/devicetree/bindings/mfd/{ => syscon}/qcom,tcsr.txt  
> > | 0
> >  Documentation/devicetree/bindings/mfd/{ => syscon}/syscon.txt 
> > | 0
> >  .../devicetree/bindings/mfd/{ => syscon}/ti-keystone-devctrl.txt  
> > | 0
> >  7 files changed, 0 insertions(+), 0 deletions(-)
> >  rename Documentation/devicetree/bindings/mfd/{ => syscon}/aspeed-scu.txt 
> > (100%)
> >  rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-gpbr.txt 
> > (100%)
> >  rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-matrix.txt 
> > (100%)
> >  rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-smc.txt 
> > (100%)
> >  rename Documentation/devicetree/bindings/mfd/{ => syscon}/qcom,tcsr.txt 
> > (100%)
> >  rename Documentation/devicetree/bindings/mfd/{ => syscon}/syscon.txt (100%)
> >  rename Documentation/devicetree/bindings/mfd/{ => 
> > syscon}/ti-keystone-devctrl.txt (100%)
> 
> I'm not so sure this is the right direction. syscon usage is pretty much 
> spread throughout the tree.

This patch was created based on my interpretation of Lee's feedback
here:

https://lkml.org/lkml/2016/11/18/650

Lee's next email in the chain poked Arnd for an opinion, but Arnd
didn't reply.

I don't mind. I moved these bindings separately so we could just drop
the patch if there was push-back. If we drop the whole idea I'll need
to apply a small fix to patch 5/6 to avoid creating the syscon
subdirectory.

Andrew

> 
> Rob

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


Re: [PATCH v2] audit: use proper refcount locking on audit_sock

2016-12-12 Thread Richard Guy Briggs
On 2016-12-12 12:10, Paul Moore wrote:
> On Mon, Dec 12, 2016 at 5:03 AM, Richard Guy Briggs  wrote:
> > Resetting audit_sock appears to be racy.
> >
> > audit_sock was being copied and dereferenced without using a refcount on
> > the source sock.
> >
> > Bump the refcount on the underlying sock when we store a refrence in
> > audit_sock and release it when we reset audit_sock.  audit_sock
> > modification needs the audit_cmd_mutex.
> >
> > See: https://lkml.org/lkml/2016/11/26/232
> >
> > Thanks to Eric Dumazet  and Cong Wang
> >  on ideas how to fix it.
> >
> > Signed-off-by: Richard Guy Briggs 
> > ---
> > There has been a lot of change in the audit code that is about to go
> > upstream to address audit queue issues.  This patch is based on the
> > source tree: git://git.infradead.org/users/pcmoore/audit#next
> > ---
> >  kernel/audit.c |   34 --
> >  1 files changed, 28 insertions(+), 6 deletions(-)
> 
> This is coming in pretty late for the v4.10 merge window, much later
> than I would usually take things, but this is arguably important, and
> (at first glance) relatively low risk - what testing have you done on
> this?

At this point, compile and boot, and I'm able to compile and run the
supplied test code without any issues.

> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index f20eee0..439f7f3 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -452,7 +452,9 @@ static void auditd_reset(void)
> > struct sk_buff *skb;
> >
> > /* break the connection */
> > +   sock_put(audit_sock);
> > audit_pid = 0;
> > +   audit_nlk_portid = 0;
> > audit_sock = NULL;
> >
> > /* flush all of the retry queue to the hold queue */
> > @@ -478,6 +480,12 @@ static int kauditd_send_unicast_skb(struct sk_buff 
> > *skb)
> > if (rc >= 0) {
> > consume_skb(skb);
> > rc = 0;
> > +   } else {
> > +   if (rc & (-ENOMEM|-EPERM|-ECONNREFUSED)) {
> > +   mutex_lock(_cmd_mutex);
> > +   auditd_reset();
> > +   mutex_unlock(_cmd_mutex);
> > +   }
> > }
> >
> > return rc;
> > @@ -579,7 +587,9 @@ static int kauditd_thread(void *dummy)
> >
> > auditd = 0;
> > if (AUDITD_BAD(rc, reschedule)) {
> > +   mutex_lock(_cmd_mutex);
> > auditd_reset();
> > +   mutex_unlock(_cmd_mutex);
> > reschedule = 0;
> > }
> > } else
> > @@ -594,7 +604,9 @@ static int kauditd_thread(void *dummy)
> > auditd = 0;
> > if (AUDITD_BAD(rc, reschedule)) {
> > kauditd_hold_skb(skb);
> > +   mutex_lock(_cmd_mutex);
> > auditd_reset();
> > +   mutex_unlock(_cmd_mutex);
> > reschedule = 0;
> > } else
> > /* temporary problem (we hope), 
> > queue
> > @@ -623,7 +635,9 @@ quick_loop:
> > if (rc) {
> > auditd = 0;
> > if (AUDITD_BAD(rc, reschedule)) {
> > +   
> > mutex_lock(_cmd_mutex);
> > auditd_reset();
> > +   
> > mutex_unlock(_cmd_mutex);
> > reschedule = 0;
> > }
> >
> > @@ -1004,17 +1018,22 @@ static int audit_receive_msg(struct sk_buff *skb, 
> > struct nlmsghdr *nlh)
> > return -EACCES;
> > }
> > if (audit_pid && new_pid &&
> > -   audit_replace(requesting_pid) != -ECONNREFUSED) 
> > {
> > +   (audit_replace(requesting_pid) & 
> > (-ECONNREFUSED|-EPERM|-ENOMEM))) {
> > audit_log_config_change("audit_pid", 
> > new_pid, audit_pid, 0);
> > return -EEXIST;
> > }
> > if (audit_enabled != AUDIT_OFF)
> > audit_log_config_change("audit_pid", 
> > new_pid, audit_pid, 1);
> > -   audit_pid = new_pid;
> > -   audit_nlk_portid = NETLINK_CB(skb).portid;
> > -   audit_sock = skb->sk;
> > -   

Re: [PATCH v3 4/6] mfd: dt: Add bindings for the Aspeed LPC Host Controller (LHC)

2016-12-12 Thread Andrew Jeffery
On Mon, 2016-12-12 at 09:30 -0600, Rob Herring wrote:
> On Tue, Dec 06, 2016 at 01:53:19PM +1100, Andrew Jeffery wrote:
> > The LPC bus pinmux configuration on fifth generation Aspeed SoCs depends
> > on bits in both the System Control Unit and the LPC Host Controller.
> > 
> > The Aspeed LPC Host Controller is described as a child node of the
> > LPC host-range syscon device for arbitration of access by the host
> > controller and pinmux drivers.
> > 
> > > > Signed-off-by: Andrew Jeffery 
> > ---
> >  .../devicetree/bindings/mfd/aspeed-lpc.txt | 22 
> > ++
> >  1 file changed, 22 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt 
> > b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> > index a97131aba446..9de318ef72da 100644
> > --- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> > +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> > > > @@ -109,3 +109,25 @@ lpc: lpc@1e789000 {
> > > >     };
> >  };
> >  
> > +Host Node Children
> > +==
> > +
> > +LPC Host Controller
> > +---
> > +
> > +The Aspeed LPC Host Controller configures the Low Pin Count (LPC) bus 
> > behaviour
> > +between the host and the baseboard management controller. The registers 
> > exist
> > +in the "host" portion of the Aspeed LPC controller, which must be the 
> > parent of
> > +the LPC host controller node.
> > +
> > +Required properties:
> > > > +- compatible:  "aspeed,ast2500-lhc";
> > > > +- reg: contains offset/length value of the LHC memory
> > +   region.
> 
> How many regions? Looks like 2.

Yes, two. The first region is registers configuring various LPC host
controller properties. The second region is for configuring the LPC
serial IRQ trigger modes.

Would you like me to say as much in the patch? It's not a completely
clear split of functionality as other serial IRQ properties are also
described in the first region. Maybe describing the datasheet's
register names for the regions (LHCR[0-8] for the first, LHCR[A-B] for
the second) would help?

Cheers,

Andrew

> 
> > +
> > +Example:
> > +
> > > > +lhc: lhc@20 {
> > > > +   compatible = "aspeed,ast2500-lhc";
> > > > +   reg = <0x20 0x24 0x48 0x8>;
> > +};
> > -- 
> > 2.9.3
> > 

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


Re: [PATCH v5 2/2] mmc: sdhci-cadence: add Cadence SD4HC support

2016-12-12 Thread Masahiro Yamada
Hi Rob.

2016-12-13 2:14 GMT+09:00 Rob Herring :
>> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt 
>> b/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
>> new file mode 100644
>> index 000..750374f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
>> @@ -0,0 +1,30 @@
>> +* Cadence SD/SDIO/eMMC Host Controller
>> +
>> +Required properties:
>> +- compatible: should be "cdns,sd4hc".
>
> Needs SoC specific compatible strings too.


I remember you mentioned the vendor prefix
stands for the SoC vendor, not the IP vendor.
The compatible prefixed with the IP vendor is prepared for a fallback.

I will add "socionext,sd4hc".




>> +- reg: offset and length of the register set for the device.
>> +- interrupts: a single interrupt specifier.
>> +- clocks: phandle to the input clock.
>> +
>> +Optional properties:
>> +For eMMC configuration, supported speed modes are not indicated by the SDHCI
>> +Capabilities Register.  Instead, the following properties should be 
>> specified
>> +if supported.  See mmc.txt for details.
>> +- mmc-ddr-1_8v
>> +- mmc-ddr-1_2v
>> +- mmc-hs200-1_8v
>> +- mmc-hs200-1_2v
>> +- mmc-hs400-1_8v
>> +- mmc-hs400-1_2v
>
> There's now a property to override SDHCI capabilities register. Maybe
> you should use that instead? I'll defer to Ulf.
>

I did not know this new property.

So, now we have two ways to specify MMC speed mode capabilities
by only touching DT.

[1] Add MMC mode flags directly, like I did.
[2] Use "sdhci-caps-mask" and "sdhci-caps"


The problem for [2] is that eMMC capabilities
do not perfectly correspond to the SDHCI capabilities register.


>> +- mmc-hs400-1_8v
>> +- mmc-hs400-1_2v

If the driver sets SDHCI_QUIRK2_CAPS_BIT63_FOR_HS400,
we can use the bit63 of caps for specifying HS400.

But, this is not defined in the SDHCI standard.
#define  SDHCI_SUPPORT_HS400 0x8000 /* Non-standard */



>> +- mmc-ddr-1_8v

For High Speed DDR, perhaps we can imply MMC_CAP_1_8V_DDR
from MMC_CAP_UHS_DDR50  (bit34 of caps)

This is not supported in the current code, but
if this is a good idea, I can send a patch.


>> +- mmc-ddr-1_2v

This does not have the corresponding bit, but
1.2V is not commonly used, so this is not a fatal problem.



What I can do at most now, is to delete the
Optional properties section entirely
so users can choose [1] or [2] as they like.



-- 
Best Regards
Masahiro Yamada


Re: [PATCH V2 for-next 00/11] Code improvements & fixes for HNS RoCE driver

2016-12-12 Thread Doug Ledford
On 11/15/2016 1:10 PM, Salil Mehta wrote:
> This patchset introduces some code improvements and fixes
> for the identified problems in the HNS RoCE driver.
> 
> Lijun Ou (4):
>   IB/hns: Add the interface for querying QP1
>   IB/hns: add self loopback for CM
>   IB/hns: Modify the condition of notifying hardware loopback
>   IB/hns: Fix the bug for qp state in hns_roce_v1_m_qp()
> 
> Salil Mehta (1):
>   IB/hns: Fix for Checkpatch.pl comment style errors
> 
> Shaobo Xu (1):
>   IB/hns: Implement the add_gid/del_gid and optimize the GIDs
> management
> 
> Wei Hu (Xavier) (5):
>   IB/hns: Add code for refreshing CQ CI using TPTR
>   IB/hns: Optimize the logic of allocating memory using APIs
>   IB/hns: Modify the macro for the timeout when cmd process
>   IB/hns: Modify query info named port_num when querying RC QP
>   IB/hns: Change qpn allocation to round-robin mode.
> 
>  drivers/infiniband/hw/hns/hns_roce_alloc.c  |   11 +-
>  drivers/infiniband/hw/hns/hns_roce_cmd.c|8 +-
>  drivers/infiniband/hw/hns/hns_roce_cmd.h|7 +-
>  drivers/infiniband/hw/hns/hns_roce_common.h |2 -
>  drivers/infiniband/hw/hns/hns_roce_cq.c |   17 +-
>  drivers/infiniband/hw/hns/hns_roce_device.h |   45 ++--
>  drivers/infiniband/hw/hns/hns_roce_eq.c |6 +-
>  drivers/infiniband/hw/hns/hns_roce_hem.c|6 +-
>  drivers/infiniband/hw/hns/hns_roce_hw_v1.c  |  267 +--
>  drivers/infiniband/hw/hns/hns_roce_hw_v1.h  |   17 +-
>  drivers/infiniband/hw/hns/hns_roce_main.c   |  311 
> +++
>  drivers/infiniband/hw/hns/hns_roce_mr.c |   21 +-
>  drivers/infiniband/hw/hns/hns_roce_pd.c |5 +-
>  drivers/infiniband/hw/hns/hns_roce_qp.c |2 +-
>  14 files changed, 363 insertions(+), 362 deletions(-)
> 

Series applied, thanks.

-- 
Doug Ledford 
GPG Key ID: 0E572FDD



signature.asc
Description: OpenPGP digital signature


Re: [GIT pull] x86/cache: Updates for 4.10

2016-12-12 Thread Linus Torvalds
On Mon, Dec 12, 2016 at 1:53 AM, Thomas Gleixner  wrote:
>
> This update provides the support for Intel Cache Allocation Technology, a
> cache partitioning mechanism.

Ugh, this is some funky stuff. And it's entirely x86-specific, with a
rather odd special filesystem interface.

It looks pretty self-contained (good), but it also looks majorly
strange. I will have to think about this. What are the main/expected
users?

Linus


[PATCH v2] ACPI/NUMA: Do not map pxm to node when NUMA is turned off

2016-12-12 Thread Boris Ostrovsky
Otherwise we may unexpectedly reference a non-zero node via, for example,
acpi_get_node() while other parts of the kernel assume that only node 0
(which is what NUMA_NO_NODE is supposed to be converted to) is
available.

Signed-off-by: Boris Ostrovsky 
---
V2:
* Drop __initdata from x86's numa_off 
* Make numa_off available to drivers/acpi/numa.c for arm64 and IA64 

 arch/arm64/include/asm/numa.h | 2 ++
 arch/arm64/mm/numa.c  | 2 +-
 arch/ia64/include/asm/numa.h  | 2 ++
 arch/x86/mm/numa.c| 2 +-
 drivers/acpi/numa.c   | 2 +-
 5 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
index 600887e..bf466d1 100644
--- a/arch/arm64/include/asm/numa.h
+++ b/arch/arm64/include/asm/numa.h
@@ -15,6 +15,8 @@
 
 extern nodemask_t numa_nodes_parsed __initdata;
 
+extern bool numa_off;
+
 /* Mappings between node number and cpus on that node. */
 extern cpumask_var_t node_to_cpumask_map[MAX_NUMNODES];
 void numa_clear_node(unsigned int cpu);
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index 4b32168..b388a99 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -35,7 +35,7 @@
 
 static int numa_distance_cnt;
 static u8 *numa_distance;
-static bool numa_off;
+bool numa_off;
 
 static __init int numa_parse_early_param(char *opt)
 {
diff --git a/arch/ia64/include/asm/numa.h b/arch/ia64/include/asm/numa.h
index 2db0a6c..ebef7f4 100644
--- a/arch/ia64/include/asm/numa.h
+++ b/arch/ia64/include/asm/numa.h
@@ -65,6 +65,8 @@ struct node_cpuid_s {
 
 #define local_nodeid (cpu_to_node_map[smp_processor_id()])
 
+#define numa_off 0
+
 extern void map_cpu_to_node(int cpu, int nid);
 extern void unmap_cpu_from_node(int cpu, int nid);
 extern void numa_clear_node(int cpu);
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index 3f35b48..12dcad7 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -19,7 +19,7 @@
 
 #include "numa_internal.h"
 
-int __initdata numa_off;
+int numa_off;
 nodemask_t numa_nodes_parsed __initdata;
 
 struct pglist_data *node_data[MAX_NUMNODES] __read_mostly;
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index ce3a7a1..edb0c79 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -70,7 +70,7 @@ int acpi_map_pxm_to_node(int pxm)
 {
int node;
 
-   if (pxm < 0 || pxm >= MAX_PXM_DOMAINS)
+   if (pxm < 0 || pxm >= MAX_PXM_DOMAINS || numa_off)
return NUMA_NO_NODE;
 
node = pxm_to_node_map[pxm];
-- 
1.8.3.1



RE: [PATCH v2 9/9] NTB: Add ntb.h comments

2016-12-12 Thread Allen Hubbe
From: Serge Semin
> 
> Signed-off-by: Serge Semin 
> 
> ---
>  include/linux/ntb.h | 17 +++--
>  1 file changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/include/linux/ntb.h b/include/linux/ntb.h
> index fe0437c..c5a369c 100644
> --- a/include/linux/ntb.h
> +++ b/include/linux/ntb.h
> @@ -312,13 +312,18 @@ static inline int ntb_dev_ops_is_valid(const struct 
> ntb_dev_ops
> *ops)
>  {
>   /* commented callbacks are not required: */
>   return
> + /* Port operations are required */

Maybe: are required for multiport devices.

>   ops->port_number&&
>   ops->peer_port_count&&
>   ops->peer_port_number   &&
>   ops->peer_port_idx  &&
> +
> + /* Link operations are requiered */
>   ops->link_is_up &&
>   ops->link_enable&&
>   ops->link_disable   &&

Wasn't the first patch in this series all about making link ops first?

> +
> + /* One or both MW interfaces should be developed */
>   ops->mw_count   &&
>   ops->mw_get_align   &&
>   (ops->mw_set_trans  ||
> @@ -328,12 +333,11 @@ static inline int ntb_dev_ops_is_valid(const struct 
> ntb_dev_ops
> *ops)
>   ops->peer_mw_get_addr   &&
>   /* ops->peer_mw_clear_trans && */
> 
> + /* Doorbell operations are mostly required */
>   /* ops->db_is_unsafe&& */
>   ops->db_valid_mask  &&
> -
>   /* both set, or both unset */
>   (!ops->db_vector_count == !ops->db_vector_mask) &&
> -
>   ops->db_read&&
>   /* ops->db_set  && */
>   ops->db_clear   &&
> @@ -347,6 +351,8 @@ static inline int ntb_dev_ops_is_valid(const struct 
> ntb_dev_ops *ops)
>   /* ops->peer_db_read_mask   && */
>   /* ops->peer_db_set_mask&& */
>   /* ops->peer_db_clear_mask  && */
> +
> + /* Scrachpad interface is optional */
>   /* !ops->spad_is_unsafe == !ops->spad_count && */
>   !ops->spad_read == !ops->spad_count &&
>   !ops->spad_write == !ops->spad_count&&
> @@ -354,6 +360,7 @@ static inline int ntb_dev_ops_is_valid(const struct 
> ntb_dev_ops *ops)
>   /* !ops->peer_spad_read == !ops->spad_count && */
>   !ops->peer_spad_write == !ops->spad_count &&
> 
> + /* Message registers interface is optional */
>   !ops->msg_inbits == !ops->msg_count &&
>   !ops->msg_outbits == !ops->msg_count&&
>   !ops->msg_read_sts == !ops->msg_count   &&
> @@ -374,13 +381,12 @@ struct ntb_client {
>   struct device_driverdrv;
>   const struct ntb_client_ops ops;
>  };
> -
>  #define drv_ntb_client(__drv) container_of((__drv), struct ntb_client, drv)
> 
>  /**
>   * struct ntb_device - ntb device
>   * @dev: Linux device object.
> - * @pdev:Pci device entry of the ntb.
> + * @pdev:PCI device entry of the ntb.
>   * @topo:Detected topology of the ntb.
>   * @ops: See _dev_ops.
>   * @ctx: See _ctx_ops.
> @@ -401,7 +407,6 @@ struct ntb_dev {
>   /* block unregister until device is fully released */
>   struct completion   released;
>  };
> -
>  #define dev_ntb(__dev) container_of((__dev), struct ntb_dev, dev)
> 
>  /**
> @@ -498,7 +503,7 @@ void ntb_link_event(struct ntb_dev *ntb);
>   * multiple interrupt vectors for doorbells, the vector number indicates 
> which
>   * vector received the interrupt.  The vector number is relative to the first
>   * vector used for doorbells, starting at zero, and must be less than
> - ** ntb_db_vector_count().  The driver may call ntb_db_read() to check which
> + * ntb_db_vector_count().  The driver may call ntb_db_read() to check which
>   * doorbell bits need service, and ntb_db_vector_mask() to determine which of
>   * those bits are associated with the vector number.
>   */
> --
> 2.6.6




RE: [PATCH v2 7/9] NTB: Add new Memory Windows API documentation

2016-12-12 Thread Allen Hubbe
From: Serge Semin
> Since the new API slightly changes the way a typical NTB client driver
> works, the documentation file needs to be appropriately updated.
> 
> Signed-off-by: Serge Semin 

Acked-by: Allen Hubbe 

> 
> ---
>  Documentation/ntb.txt | 99 
> ++-
>  1 file changed, 91 insertions(+), 8 deletions(-)
> 
> diff --git a/Documentation/ntb.txt b/Documentation/ntb.txt
> index 1d9bbab..d01bb69 100644
> --- a/Documentation/ntb.txt
> +++ b/Documentation/ntb.txt
> @@ -1,14 +1,16 @@
>  # NTB Drivers
> 
>  NTB (Non-Transparent Bridge) is a type of PCI-Express bridge chip that 
> connects
> -the separate memory systems of two computers to the same PCI-Express fabric.
> -Existing NTB hardware supports a common feature set, including scratchpad
> -registers, doorbell registers, and memory translation windows.  Scratchpad
> -registers are read-and-writable registers that are accessible from either 
> side
> -of the device, so that peers can exchange a small amount of information at a
> -fixed address.  Doorbell registers provide a way for peers to send interrupt
> -events.  Memory windows allow translated read and write access to the peer
> -memory.
> +the separate memory systems of two or more computers to the same PCI-Express
> +fabric. Existing NTB hardware supports a common feature set: doorbell
> +registers and memory translation windows, as well as non common features like
> +scratchpad and message registers. Scratchpad registers are read-and-writable
> +registers that are accessible from either side of the device, so that peers 
> can
> +exchange a small amount of information at a fixed address. Message registers 
> can
> +be utialized for the same purpose. Additionally they are provided with with
> +special status bits to make sure the information isn't rewritten by another
> +peer. Doorbell registers provide a way for peers to send interrupt events.
> +Memory windows allow translated read and write access to the peer memory.
> 
>  ## NTB Core Driver (ntb)
> 
> @@ -26,6 +28,87 @@ as ntb hardware, or hardware drivers, are inserted and 
> removed.  The
>  registration uses the Linux Device framework, so it should feel familiar to
>  anyone who has written a pci driver.
> 
> +### NTB Typical client driver implementation
> +
> +Primary purpose of NTB is to share some peace of memory between at least two
> +systems. So the NTB device features like Scratchpad/Message regiesters are
> +mainly used to perform the proper memory window initialization. Typically
> +there are two types of memory window interfaces supported by the NTB API:
> +inbound translation configured on the local ntb port and outbound translation
> +configured by the peer, on the peer ntb port. The first type is
> +depicted on the next figure
> +
> +Inbound translation:
> + Memory:  Local NTB Port:  Peer NTB Port:  Peer MMIO:
> +  
> + | dma-mapped |-ntb_mw_set_trans(addr)  |
> + | memory |_v   |   __
> + | (addr) |<==| MW xlat addr |<| MW base addr |<== memory-mapped 
> IO
> + ||   |--|  |  |--|
> +
> +So typical scenario of the first type memory window initialization looks:
> +1) allocate a memory region, 2) put translated address to NTB config,
> +3) somehow notify a peer device of performed initialization, 4) peer device
> +maps corresponding outbound memory window so to have access to the shared
> +memory region.
> +
> +The second type of interface, that implies the shared windows being
> +initialized by a peer device, is depicted on the figure:
> +
> +Outbound translation:
> + Memory:Local NTB Port:Peer NTB Port:  Peer MMIO:
> +    __
> + | dma-mapped ||   | MW base addr |<== memory-mapped IO
> + | memory ||   |--|
> + | (addr) |<===| MW xlat addr 
> |<-ntb_peer_mw_set_trans(addr)
> + |||   |--|
> +
> +Typical scenario of the second type interface initialization would be:
> +1) allocate a memory region, 2) somehow deliver a translated address to a 
> peer
> +device, 3) peer puts the translated address to NTB config, 4) peer device 
> maps
> +outbound memory window so to have access to the shared memory region.
> +
> +As one can see the described scenarios can be combined in one portable
> +algorithm.
> + Local device:
> +  1) Allocate memory for a shared window
> +  2) Initialize memory window by translated address of the allocated region
> + (it may fail if local memory window initialzation is unsupported)
> +  3) Send the translated address and memory window index to a peer device
> + Peer device:
> +  1) Initialize memory window with retrieved address of the allocated
> + by another device memory region (it may fail if peer memory window
> + 

RE: [PATCH v2 8/9] NTB: Add PCIe Gen4 link speed

2016-12-12 Thread Allen Hubbe
From: Serge Semin
> 
> Signed-off-by: Serge Semin 

Acked-by: Allen Hubbe 

> 
> ---
>  include/linux/ntb.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/linux/ntb.h b/include/linux/ntb.h
> index 90746df..fe0437c 100644
> --- a/include/linux/ntb.h
> +++ b/include/linux/ntb.h
> @@ -108,6 +108,7 @@ static inline char *ntb_topo_string(enum ntb_topo topo)
>   * @NTB_SPEED_GEN1:  Link is trained to gen1 speed.
>   * @NTB_SPEED_GEN2:  Link is trained to gen2 speed.
>   * @NTB_SPEED_GEN3:  Link is trained to gen3 speed.
> + * @NTB_SPEED_GEN4:  Link is trained to gen4 speed.
>   */
>  enum ntb_speed {
>   NTB_SPEED_AUTO = -1,
> @@ -115,6 +116,7 @@ enum ntb_speed {
>   NTB_SPEED_GEN1 = 1,
>   NTB_SPEED_GEN2 = 2,
>   NTB_SPEED_GEN3 = 3,
> + NTB_SPEED_GEN4 = 4
>  };
> 
>  /**
> --
> 2.6.6




RE: [PATCH v2 6/9] NTB: Add Messaging NTB API

2016-12-12 Thread Allen Hubbe
From: Serge Semin
> Some IDT NTB-capable PCIe-switches have message registers to communicate with
> peer devices. This patch adds new NTB API callback methods, which can be used
> to utilize these registers functionality:
>  ntb_msg_count(); - get number of message registers
>  ntb_msg_inbits(); - get bitfield of inbound message registers status
>  ntb_msg_outbits(); - get bitfield of outbound message registers status
>  ntb_msg_read_sts(); - read the inbound and outbound message registers status
>  ntb_msg_clear_sts(); - clear status bits of message registers
>  ntb_msg_set_mask(); - mask interrupts raised by status bits of message
> registers.
>  ntb_msg_clear_mask(); - clear interrupts mask bits of message registers
>  ntb_msg_read(midx, *pidx); - read message register with specified index,
> additionally getting peer port index which data received from
>  ntb_msg_write(midx, pidx); - write data to the specified message register
> sending it to the passed peer device connected over a pidx port
>  ntb_msg_event(); - notify driver context of a new message event
> 
> Of course there is hadrware which doesn't support Message registers, so

s/hadrware/hardware/

> this API is made optional.
> 
> Signed-off-by: Serge Semin 

Acked-by: Allen Hubbe 

> 
> ---
>  drivers/ntb/ntb.c   |  13 
>  include/linux/ntb.h | 205 
> 
>  2 files changed, 218 insertions(+)
> 
> diff --git a/drivers/ntb/ntb.c b/drivers/ntb/ntb.c
> index f6153af..06574f8 100644
> --- a/drivers/ntb/ntb.c
> +++ b/drivers/ntb/ntb.c
> @@ -193,6 +193,19 @@ void ntb_db_event(struct ntb_dev *ntb, int vector)
>  }
>  EXPORT_SYMBOL(ntb_db_event);
> 
> +void ntb_msg_event(struct ntb_dev *ntb)
> +{
> + unsigned long irqflags;
> +
> + spin_lock_irqsave(>ctx_lock, irqflags);
> + {
> + if (ntb->ctx_ops && ntb->ctx_ops->msg_event)
> + ntb->ctx_ops->msg_event(ntb->ctx);
> + }
> + spin_unlock_irqrestore(>ctx_lock, irqflags);
> +}
> +EXPORT_SYMBOL(ntb_msg_event);
> +
>  static int ntb_probe(struct device *dev)
>  {
>   struct ntb_dev *ntb;
> diff --git a/include/linux/ntb.h b/include/linux/ntb.h
> index a6bf15d..90746df 100644
> --- a/include/linux/ntb.h
> +++ b/include/linux/ntb.h
> @@ -164,10 +164,12 @@ static inline int ntb_client_ops_is_valid(const struct
> ntb_client_ops *ops)
>   * struct ntb_ctx_ops - ntb driver context operations
>   * @link_event:  See ntb_link_event().
>   * @db_event:See ntb_db_event().
> + * @msg_event:   See ntb_msg_event().
>   */
>  struct ntb_ctx_ops {
>   void (*link_event)(void *ctx);
>   void (*db_event)(void *ctx, int db_vector);
> + void (*msg_event)(void *ctx);
>  };
> 
>  static inline int ntb_ctx_ops_is_valid(const struct ntb_ctx_ops *ops)
> @@ -176,6 +178,7 @@ static inline int ntb_ctx_ops_is_valid(const struct 
> ntb_ctx_ops *ops)
>   return
>   /* ops->link_event  && */
>   /* ops->db_event&& */
> + /* ops->msg_event   && */
>   1;
>  }
> 
> @@ -220,6 +223,15 @@ static inline int ntb_ctx_ops_is_valid(const struct 
> ntb_ctx_ops *ops)
>   * @peer_spad_addr:  See ntb_peer_spad_addr().
>   * @peer_spad_read:  See ntb_peer_spad_read().
>   * @peer_spad_write: See ntb_peer_spad_write().
> + * @msg_count:   See ntb_msg_count().
> + * @msg_inbits:  See ntb_msg_inbits().
> + * @msg_outbits: See ntb_msg_outbits().
> + * @msg_read_sts:See ntb_msg_read_sts().
> + * @msg_clear_sts:   See ntb_msg_clear_sts().
> + * @msg_set_mask:See ntb_msg_set_mask().
> + * @msg_clear_mask:  See ntb_msg_clear_mask().
> + * @msg_read:See ntb_msg_read().
> + * @msg_write:   See ntb_msg_write().
>   */
>  struct ntb_dev_ops {
>   int (*port_number)(struct ntb_dev *ntb);
> @@ -282,6 +294,16 @@ struct ntb_dev_ops {
>   u32 (*peer_spad_read)(struct ntb_dev *ntb, int pidx, int sidx);
>   int (*peer_spad_write)(struct ntb_dev *ntb, int pidx, int sidx,
>  u32 val);
> +
> + int (*msg_count)(struct ntb_dev *ntb);
> + u64 (*msg_inbits)(struct ntb_dev *ntb);
> + u64 (*msg_outbits)(struct ntb_dev *ntb);
> + u64 (*msg_read_sts)(struct ntb_dev *ntb);
> + int (*msg_clear_sts)(struct ntb_dev *ntb, u64 sts_bits);
> + int (*msg_set_mask)(struct ntb_dev *ntb, u64 mask_bits);
> + int (*msg_clear_mask)(struct ntb_dev *ntb, u64 mask_bits);
> + int (*msg_read)(struct ntb_dev *ntb, int midx, int *pidx, u32 *msg);
> + int (*msg_write)(struct ntb_dev *ntb, int midx, int pidx, u32 msg);
>  };
> 
>  static inline int ntb_dev_ops_is_valid(const struct ntb_dev_ops *ops)
> @@ -329,6 +351,15 @@ static inline int ntb_dev_ops_is_valid(const struct 
> ntb_dev_ops *ops)
>   /* !ops->peer_spad_addr == !ops->spad_count && */
>  

RE: [PATCH v2 5/9] NTB: Alter Scratchpads API to support multi-ports devices

2016-12-12 Thread Allen Hubbe
From: Serge Semin 
> Even though there is no any real NTB hardware, which would have both more
> than two ports and Scratchpad registers, it is logically correct to have
> Scratchpad API accepting a peer port index as well. Intel/AMD drivers utilize
> Primary and Secondary topology to split Scratchpad between connected root
> devices. Since port-index API introduced, Intel/AMD NTB hadrware drivers can

s/hadrware/hardware/

> use device port to determine which Scratchpad registers actually belong to
> local and peer devices. The same approach can be used if some potential
> hardware in future will be multi-port and have some set of Scratchpads.
> Here are the brief of changes in the API:
>  ntb_spad_count() - return number of Scratchpad per each port
>  ntb_peer_spad_addr(pidx, sidx) - address of Scratchpad register of the
> peer device with pidx-index
>  ntb_peer_spad_read(pidx, sidx) - read specified Scratchpad register of the
> peer with pidx-index
>  ntb_peer_spad_write(pidx, sidx) - write data to Scratchpad register of the
> peer with pidx-index
> 
> Since there is hardware which doesn't support Scratchpad registers, the
> corresponding API methods are now made optional.

The api change looks good.  See the comment to simplify ntb_tool.

> Signed-off-by: Serge Semin 
> 
> ---
>  drivers/ntb/hw/amd/ntb_hw_amd.c | 14 +++
>  drivers/ntb/hw/intel/ntb_hw_intel.c | 14 +++
>  drivers/ntb/ntb_transport.c | 17 -
>  drivers/ntb/test/ntb_perf.c |  6 +--
>  drivers/ntb/test/ntb_pingpong.c |  8 +++-
>  drivers/ntb/test/ntb_tool.c | 45 +-
>  include/linux/ntb.h | 76 
> +++--
>  7 files changed, 115 insertions(+), 65 deletions(-)
> 
> diff --git a/drivers/ntb/hw/amd/ntb_hw_amd.c b/drivers/ntb/hw/amd/ntb_hw_amd.c
> index 74fe9b8..a2596ad 100644
> --- a/drivers/ntb/hw/amd/ntb_hw_amd.c
> +++ b/drivers/ntb/hw/amd/ntb_hw_amd.c
> @@ -476,30 +476,30 @@ static int amd_ntb_spad_write(struct ntb_dev *ntb,
>   return 0;
>  }
> 
> -static u32 amd_ntb_peer_spad_read(struct ntb_dev *ntb, int idx)
> +static u32 amd_ntb_peer_spad_read(struct ntb_dev *ntb, int pidx, int sidx)
>  {
>   struct amd_ntb_dev *ndev = ntb_ndev(ntb);
>   void __iomem *mmio = ndev->self_mmio;
>   u32 offset;
> 
> - if (idx < 0 || idx >= ndev->spad_count)
> + if (sidx < 0 || sidx >= ndev->spad_count)
>   return -EINVAL;
> 
> - offset = ndev->peer_spad + (idx << 2);
> + offset = ndev->peer_spad + (sidx << 2);
>   return readl(mmio + AMD_SPAD_OFFSET + offset);
>  }
> 
> -static int amd_ntb_peer_spad_write(struct ntb_dev *ntb,
> -int idx, u32 val)
> +static int amd_ntb_peer_spad_write(struct ntb_dev *ntb, int pidx,
> +int sidx, u32 val)
>  {
>   struct amd_ntb_dev *ndev = ntb_ndev(ntb);
>   void __iomem *mmio = ndev->self_mmio;
>   u32 offset;
> 
> - if (idx < 0 || idx >= ndev->spad_count)
> + if (sidx < 0 || sidx >= ndev->spad_count)
>   return -EINVAL;
> 
> - offset = ndev->peer_spad + (idx << 2);
> + offset = ndev->peer_spad + (sidx << 2);
>   writel(val, mmio + AMD_SPAD_OFFSET + offset);
> 
>   return 0;
> diff --git a/drivers/ntb/hw/intel/ntb_hw_intel.c 
> b/drivers/ntb/hw/intel/ntb_hw_intel.c
> index 5a57d9e..471b0ba 100644
> --- a/drivers/ntb/hw/intel/ntb_hw_intel.c
> +++ b/drivers/ntb/hw/intel/ntb_hw_intel.c
> @@ -1452,30 +1452,30 @@ static int intel_ntb_spad_write(struct ntb_dev *ntb,
>  ndev->self_reg->spad);
>  }
> 
> -static int intel_ntb_peer_spad_addr(struct ntb_dev *ntb, int idx,
> +static int intel_ntb_peer_spad_addr(struct ntb_dev *ntb, int pidx, int sidx,
>   phys_addr_t *spad_addr)
>  {
>   struct intel_ntb_dev *ndev = ntb_ndev(ntb);
> 
> - return ndev_spad_addr(ndev, idx, spad_addr, ndev->peer_addr,
> + return ndev_spad_addr(ndev, sidx, spad_addr, ndev->peer_addr,
> ndev->peer_reg->spad);
>  }
> 
> -static u32 intel_ntb_peer_spad_read(struct ntb_dev *ntb, int idx)
> +static u32 intel_ntb_peer_spad_read(struct ntb_dev *ntb, int pidx, int sidx)
>  {
>   struct intel_ntb_dev *ndev = ntb_ndev(ntb);
> 
> - return ndev_spad_read(ndev, idx,
> + return ndev_spad_read(ndev, sidx,
> ndev->peer_mmio +
> ndev->peer_reg->spad);
>  }
> 
> -static int intel_ntb_peer_spad_write(struct ntb_dev *ntb,
> -  int idx, u32 val)
> +static int intel_ntb_peer_spad_write(struct ntb_dev *ntb, int pidx,
> +  int sidx, u32 val)
>  {
>   struct intel_ntb_dev *ndev = ntb_ndev(ntb);
> 
> - return ndev_spad_write(ndev, idx, val,
> + return ndev_spad_write(ndev, sidx, val,
>  ndev->peer_mmio +
>

RE: [PATCH v2 4/9] NTB: Alter MW API to support multi-ports devices

2016-12-12 Thread Allen Hubbe
From: Serge Semin
> Multi-port NTB devices permit to share a memory between all accessible peers.
> Memory Windows API is altered to correspondingly initialize and map memory
> windows for such devices:
>  ntb_mw_count(pidx); - number of inbound memory windows, which can be 
> allocated
> for shared buffer with specified peer device.
>  ntb_mw_get_align(pidx, widx); - get alignment and size restrition parameters
> to properly allocate inbound memory region.
>  ntb_peer_mw_count(); - get number of outbound memory windows.
>  ntb_peer_mw_get_addr(widx); - get mapping address of an outbound memory 
> window
> 
> If hardware supports inbound translation configured on the local ntb port:
>  ntb_mw_set_trans(pidx, widx); - set translation address of allocated inbound
> memory window so a peer device could access it.
>  ntb_mw_clear_trans(pidx, widx); - clear the translation address of an inbound
> memory window.
> 
> If hadrware supports outbound translation configured on the peer ntb port:

s/hadrware/hardware/

>  ntb_peer_mw_set_trans(pidx, widx); - set translation address of a memory
> window retrieved from a peer device
>  ntb_peer_mw_clear_trans(pidx, widx); - clear the translation address of an
> outbound memory window
> 
> Signed-off-by: Serge Semin 
> 
> ---
>  drivers/ntb/hw/amd/ntb_hw_amd.c |  68 +---
>  drivers/ntb/hw/amd/ntb_hw_amd.h |   2 +
>  drivers/ntb/hw/intel/ntb_hw_intel.c |  90 
>  drivers/ntb/hw/intel/ntb_hw_intel.h |   2 +
>  drivers/ntb/ntb.c   |   2 +
>  drivers/ntb/ntb_transport.c |  21 +++-
>  drivers/ntb/test/ntb_perf.c |  17 ++-
>  drivers/ntb/test/ntb_tool.c |  43 +---
>  include/linux/ntb.h | 208 
> 
>  9 files changed, 346 insertions(+), 107 deletions(-)
> 
> diff --git a/drivers/ntb/hw/amd/ntb_hw_amd.c b/drivers/ntb/hw/amd/ntb_hw_amd.c
> index b6a4291..74fe9b8 100644
> --- a/drivers/ntb/hw/amd/ntb_hw_amd.c
> +++ b/drivers/ntb/hw/amd/ntb_hw_amd.c
> @@ -5,6 +5,7 @@
>   *   GPL LICENSE SUMMARY
>   *
>   *   Copyright (C) 2016 Advanced Micro Devices, Inc. All Rights Reserved.
> + *   Copyright (C) 2016 T-Platforms. All Rights Reserved.
>   *
>   *   This program is free software; you can redistribute it and/or modify
>   *   it under the terms of version 2 of the GNU General Public License as
> @@ -13,6 +14,7 @@
>   *   BSD LICENSE
>   *
>   *   Copyright (C) 2016 Advanced Micro Devices, Inc. All Rights Reserved.
> + *   Copyright (C) 2016 T-Platforms. All Rights Reserved.
>   *
>   *   Redistribution and use in source and binary forms, with or without
>   *   modification, are permitted provided that the following conditions
> @@ -213,40 +215,42 @@ static int ndev_mw_to_bar(struct amd_ntb_dev *ndev, int 
> idx)
>   return 1 << idx;
>  }
> 
> -static int amd_ntb_mw_count(struct ntb_dev *ntb)
> +static int amd_ntb_mw_count(struct ntb_dev *ntb, int pidx)
>  {
> + if (pidx > NTB_PIDX_MAX)
> + return -EINVAL;

pidx may be negative.  This should be if (pidx != 0) with some named constant 
for zero, or just if (pidx).

Similarly apply this comment below.

> +
>   return ntb_ndev(ntb)->mw_count;
>  }
> 
> -static int amd_ntb_mw_get_range(struct ntb_dev *ntb, int idx,
> - phys_addr_t *base,
> - resource_size_t *size,
> - resource_size_t *align,
> - resource_size_t *align_size)
> +static int amd_ntb_mw_get_align(struct ntb_dev *ntb, int pidx, int idx,
> + resource_size_t *addr_align,
> + resource_size_t *size_align,
> + resource_size_t *size_max)
>  {
>   struct amd_ntb_dev *ndev = ntb_ndev(ntb);
>   int bar;
> 
> + if (pidx > NTB_PIDX_MAX)
> + return -EINVAL;
> +
>   bar = ndev_mw_to_bar(ndev, idx);
>   if (bar < 0)
>   return bar;
> 
> - if (base)
> - *base = pci_resource_start(ndev->ntb.pdev, bar);
> -
> - if (size)
> - *size = pci_resource_len(ndev->ntb.pdev, bar);
> + if (addr_align)
> + *addr_align = SZ_4K;
> 
> - if (align)
> - *align = SZ_4K;
> + if (size_align)
> + *size_align = 1;
> 
> - if (align_size)
> - *align_size = 1;
> + if (size_max)
> + *size_max = pci_resource_len(ndev->ntb.pdev, bar);
> 
>   return 0;
>  }
> 
> -static int amd_ntb_mw_set_trans(struct ntb_dev *ntb, int idx,
> +static int amd_ntb_mw_set_trans(struct ntb_dev *ntb, int pidx, int idx,
>   dma_addr_t addr, resource_size_t size)
>  {
>   struct amd_ntb_dev *ndev = ntb_ndev(ntb);
> @@ -256,6 +260,9 @@ static int amd_ntb_mw_set_trans(struct ntb_dev *ntb, int 
> idx,
>   u64 base_addr, limit, reg_val;
>   int bar;
> 
> + if (pidx > NTB_PIDX_MAX)
> 

RE: [PATCH v2 1/9] NTB: Make link-state API being declared first

2016-12-12 Thread Allen Hubbe
From: Serge Semin
> Since link operations are usually performed before memory window access
> operations, it's logically better to declared link-related API before any
> other methods. Additionally it's good practice for readability to declare
> NTB device callback methods of hadrware drivers with the same order as it's
> done within ntb.h.

s/hadrware/hardware/

Please limit this change to ntb.h.  Leave it to the hardware driver maintainers 
to rearrange the methods in each driver if they care to.  Code movement may 
conflict with other changes in development.

> 
> Signed-off-by: Serge Semin 
> 
> ---
>  drivers/ntb/hw/amd/ntb_hw_amd.c | 188 
> ++--
>  drivers/ntb/hw/intel/ntb_hw_intel.c | 168 
>  include/linux/ntb.h | 137 +-
>  3 files changed, 247 insertions(+), 246 deletions(-)
> 
> diff --git a/drivers/ntb/hw/amd/ntb_hw_amd.c b/drivers/ntb/hw/amd/ntb_hw_amd.c
> index 6ccba0d..6704327 100644
> --- a/drivers/ntb/hw/amd/ntb_hw_amd.c
> +++ b/drivers/ntb/hw/amd/ntb_hw_amd.c
> @@ -71,6 +71,97 @@ MODULE_AUTHOR("AMD Inc.");
>  static const struct file_operations amd_ntb_debugfs_info;
>  static struct dentry *debugfs_dir;
> 
> +static int amd_link_is_up(struct amd_ntb_dev *ndev)
> +{
> + if (!ndev->peer_sta)
> + return NTB_LNK_STA_ACTIVE(ndev->cntl_sta);
> +
> + /* If peer_sta is reset or D0 event, the ISR has
> +  * started a timer to check link status of hardware.
> +  * So here just clear status bit. And if peer_sta is
> +  * D3 or PME_TO, D0/reset event will be happened when
> +  * system wakeup/poweron, so do nothing here.
> +  */
> + if (ndev->peer_sta & AMD_PEER_RESET_EVENT)
> + ndev->peer_sta &= ~AMD_PEER_RESET_EVENT;
> + else if (ndev->peer_sta & AMD_PEER_D0_EVENT)
> + ndev->peer_sta = 0;
> +
> + return 0;
> +}
> +
> +static int amd_ntb_link_is_up(struct ntb_dev *ntb,
> +   enum ntb_speed *speed,
> +   enum ntb_width *width)
> +{
> + struct amd_ntb_dev *ndev = ntb_ndev(ntb);
> + int ret = 0;
> +
> + if (amd_link_is_up(ndev)) {
> + if (speed)
> + *speed = NTB_LNK_STA_SPEED(ndev->lnk_sta);
> + if (width)
> + *width = NTB_LNK_STA_WIDTH(ndev->lnk_sta);
> +
> + dev_dbg(ndev_dev(ndev), "link is up.\n");
> +
> + ret = 1;
> + } else {
> + if (speed)
> + *speed = NTB_SPEED_NONE;
> + if (width)
> + *width = NTB_WIDTH_NONE;
> +
> + dev_dbg(ndev_dev(ndev), "link is down.\n");
> + }
> +
> + return ret;
> +}
> +
> +static int amd_ntb_link_enable(struct ntb_dev *ntb,
> +enum ntb_speed max_speed,
> +enum ntb_width max_width)
> +{
> + struct amd_ntb_dev *ndev = ntb_ndev(ntb);
> + void __iomem *mmio = ndev->self_mmio;
> + u32 ntb_ctl;
> +
> + /* Enable event interrupt */
> + ndev->int_mask &= ~AMD_EVENT_INTMASK;
> + writel(ndev->int_mask, mmio + AMD_INTMASK_OFFSET);
> +
> + if (ndev->ntb.topo == NTB_TOPO_SEC)
> + return -EINVAL;
> + dev_dbg(ndev_dev(ndev), "Enabling Link.\n");
> +
> + ntb_ctl = readl(mmio + AMD_CNTL_OFFSET);
> + ntb_ctl |= (PMM_REG_CTL | SMM_REG_CTL);
> + writel(ntb_ctl, mmio + AMD_CNTL_OFFSET);
> +
> + return 0;
> +}
> +
> +static int amd_ntb_link_disable(struct ntb_dev *ntb)
> +{
> + struct amd_ntb_dev *ndev = ntb_ndev(ntb);
> + void __iomem *mmio = ndev->self_mmio;
> + u32 ntb_ctl;
> +
> + /* Disable event interrupt */
> + ndev->int_mask |= AMD_EVENT_INTMASK;
> + writel(ndev->int_mask, mmio + AMD_INTMASK_OFFSET);
> +
> + if (ndev->ntb.topo == NTB_TOPO_SEC)
> + return -EINVAL;
> + dev_dbg(ndev_dev(ndev), "Enabling Link.\n");
> +
> + ntb_ctl = readl(mmio + AMD_CNTL_OFFSET);
> + ntb_ctl &= ~(PMM_REG_CTL | SMM_REG_CTL);
> + writel(ntb_ctl, mmio + AMD_CNTL_OFFSET);
> +
> + return 0;
> +}
> +
>  static int ndev_mw_to_bar(struct amd_ntb_dev *ndev, int idx)
>  {
>   if (idx < 0 || idx > ndev->mw_count)
> @@ -194,97 +285,6 @@ static int amd_ntb_mw_set_trans(struct ntb_dev *ntb, int 
> idx,
>   return 0;
>  }
> 
> -static int amd_link_is_up(struct amd_ntb_dev *ndev)
> -{
> - if (!ndev->peer_sta)
> - return NTB_LNK_STA_ACTIVE(ndev->cntl_sta);
> -
> - /* If peer_sta is reset or D0 event, the ISR has
> -  * started a timer to check link status of hardware.
> -  * So here just clear status bit. And if peer_sta is
> -  * D3 or PME_TO, D0/reset event will be happened when
> -  * system wakeup/poweron, so do nothing here.
> -  */
> - if (ndev->peer_sta & AMD_PEER_RESET_EVENT)
> - ndev->peer_sta &= ~AMD_PEER_RESET_EVENT;
> - else if 

RE: [PATCH v2 3/9] NTB: Alter link-state API to support multi-port devices

2016-12-12 Thread Allen Hubbe
From: Serge Semin
> Multi-port devices permit the NTB connections between multiple domains,
> so a local device can have NTB link being up with one peer and being
> down with another. NTB link-state API is appropriately altered to return
> a bitfield of the link-states between the local device and possible peers.
> 
> Signed-off-by: Serge Semin 

Acked-by: Allen Hubbe 

> 
> ---
>  drivers/ntb/hw/amd/ntb_hw_amd.c |  2 +-
>  drivers/ntb/hw/intel/ntb_hw_intel.c |  2 +-
>  include/linux/ntb.h | 31 ---
>  3 files changed, 18 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/ntb/hw/amd/ntb_hw_amd.c b/drivers/ntb/hw/amd/ntb_hw_amd.c
> index 0b767ef..b6a4291 100644
> --- a/drivers/ntb/hw/amd/ntb_hw_amd.c
> +++ b/drivers/ntb/hw/amd/ntb_hw_amd.c
> @@ -133,7 +133,7 @@ static int amd_link_is_up(struct amd_ntb_dev *ndev)
>   return 0;
>  }
> 
> -static int amd_ntb_link_is_up(struct ntb_dev *ntb,
> +static u64 amd_ntb_link_is_up(struct ntb_dev *ntb,
> enum ntb_speed *speed,
> enum ntb_width *width)
>  {
> diff --git a/drivers/ntb/hw/intel/ntb_hw_intel.c 
> b/drivers/ntb/hw/intel/ntb_hw_intel.c
> index 7e44dc3..f37b6fb 100644
> --- a/drivers/ntb/hw/intel/ntb_hw_intel.c
> +++ b/drivers/ntb/hw/intel/ntb_hw_intel.c
> @@ -1078,7 +1078,7 @@ static int intel_ntb_peer_port_idx(struct ntb_dev *ntb, 
> int port)
>   return 0;
>  }
> 
> -static int intel_ntb_link_is_up(struct ntb_dev *ntb,
> +static u64 intel_ntb_link_is_up(struct ntb_dev *ntb,
>   enum ntb_speed *speed,
>   enum ntb_width *width)
>  {
> diff --git a/include/linux/ntb.h b/include/linux/ntb.h
> index 3216689..47ec611 100644
> --- a/include/linux/ntb.h
> +++ b/include/linux/ntb.h
> @@ -221,7 +221,7 @@ struct ntb_dev_ops {
>   int (*peer_port_number)(struct ntb_dev *ntb, int pidx);
>   int (*peer_port_idx)(struct ntb_dev *ntb, int port);
> 
> - int (*link_is_up)(struct ntb_dev *ntb,
> + u64 (*link_is_up)(struct ntb_dev *ntb,
> enum ntb_speed *speed, enum ntb_width *width);
>   int (*link_enable)(struct ntb_dev *ntb,
>  enum ntb_speed max_speed, enum ntb_width max_width);
> @@ -522,25 +522,26 @@ static inline int ntb_peer_port_idx(struct ntb_dev 
> *ntb, int port)
>   * state once after every link event.  It is safe to query the link state in
>   * the context of the link event callback.
>   *
> - * Return: One if the link is up, zero if the link is down, otherwise a
> - *   negative value indicating the error number.
> + * Return: bitfield of indexed ports link state: bit is set/cleared if the
> + * link is up/down respectively.
>   */
> -static inline int ntb_link_is_up(struct ntb_dev *ntb,
> +static inline u64 ntb_link_is_up(struct ntb_dev *ntb,
>enum ntb_speed *speed, enum ntb_width *width)
>  {
>   return ntb->ops->link_is_up(ntb, speed, width);
>  }
> 
>  /**
> - * ntb_link_enable() - enable the link on the secondary side of the ntb
> + * ntb_link_enable() - enable the local port ntb connection
>   * @ntb: NTB device context.
>   * @max_speed:   The maximum link speed expressed as PCIe generation 
> number.
>   * @max_width:   The maximum link width expressed as the number of PCIe 
> lanes.
>   *
> - * Enable the link on the secondary side of the ntb.  This can only be done
> - * from the primary side of the ntb in primary or b2b topology.  The ntb 
> device
> - * should train the link to its maximum speed and width, or the requested 
> speed
> - * and width, whichever is smaller, if supported.
> + * Enable the NTB/PCIe link on the local or remote (for bridge-to-bridge
> + * topology) side of the bridge. If it's supported the ntb device should 
> train
> + * the link to its maximum speed and width, or the requested speed and width,
> + * whichever is smaller. Some hardware doesn't support PCIe link training, so
> + * the last two arguments will be ignored then.
>   *
>   * Return: Zero on success, otherwise an error number.
>   */
> @@ -552,14 +553,14 @@ static inline int ntb_link_enable(struct ntb_dev *ntb,
>  }
> 
>  /**
> - * ntb_link_disable() - disable the link on the secondary side of the ntb
> + * ntb_link_disable() - disable the local port ntb connection
>   * @ntb: NTB device context.
>   *
> - * Disable the link on the secondary side of the ntb.  This can only be
> - * done from the primary side of the ntb in primary or b2b topology.  The ntb
> - * device should disable the link.  Returning from this call must indicate 
> that
> - * a barrier has passed, though with no more writes may pass in either
> - * direction across the link, except if this call returns an error number.
> + * Disable the link on the local or remote (for b2b topology) of the ntb.
> + * The ntb device should disable the link.  

RE: [PATCH v2 2/9] NTB: Add indexed ports NTB API

2016-12-12 Thread Allen Hubbe
From: Serge Semin 
> There are some NTB hardware, which can combine more than just two domains
> over NTB. For instance, some IDT PCIe-switches can have NTB-functions
> activated on more than two-ports. The different domains are distinguished
> by ports they are connected to. So the new port-related methods are added to
> the NTB API:
>  ntb_port_number() - return local port
>  ntb_peer_port_count() - return number of peers local port can connect to
>  ntb_peer_port_number(pdix) - return port number by it index
>  ntb_peer_port_idx(port) - return port index by it number
> 
> Current test-drivers aren't changed much. They still support two-ports devices
> for the time being while multi-ports hardware drivers aren't added.
> 

The port methods are the same for PRI/SEC drivers.  Rather than duplicating the 
code, multiport could be made optional in the api, and default implementations 
provided by ntb common code.

Some comments below.

> Signed-off-by: Serge Semin 
> 
> ---
>  drivers/ntb/hw/amd/ntb_hw_amd.c | 47 
>  drivers/ntb/hw/amd/ntb_hw_amd.h |  9 +
>  drivers/ntb/hw/intel/ntb_hw_intel.c | 52 ++-
>  drivers/ntb/hw/intel/ntb_hw_intel.h |  9 +
>  drivers/ntb/ntb_transport.c |  6 
>  drivers/ntb/test/ntb_perf.c |  4 +++
>  drivers/ntb/test/ntb_pingpong.c |  6 
>  drivers/ntb/test/ntb_tool.c |  5 +++
>  include/linux/ntb.h | 71 
> +
>  9 files changed, 208 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/ntb/hw/amd/ntb_hw_amd.c b/drivers/ntb/hw/amd/ntb_hw_amd.c
> index 6704327..0b767ef 100644
> --- a/drivers/ntb/hw/amd/ntb_hw_amd.c
> +++ b/drivers/ntb/hw/amd/ntb_hw_amd.c
> @@ -71,6 +71,49 @@ MODULE_AUTHOR("AMD Inc.");
>  static const struct file_operations amd_ntb_debugfs_info;
>  static struct dentry *debugfs_dir;
> 
> +static int amd_ntb_port_number(struct ntb_dev *ntb)
> +{
> + switch (ntb->topo) {
> + case NTB_TOPO_PRI:
> + case NTB_TOPO_B2B_USD:
> + return NTB_PORT_PRI_USD;
> + case NTB_TOPO_SEC:
> + case NTB_TOPO_B2B_DSD:
> + return NTB_PORT_SEC_DSD;
> + default:
> + break;
> + }
> +
> + return -EINVAL;
> +}
> +
> +static int amd_ntb_peer_port_count(struct ntb_dev *ntb)
> +{
> + return NTB_PEER_CNT;
> +}
> +
> +static int amd_ntb_peer_port_number(struct ntb_dev *ntb, int pidx)
> +{
> + int local_port = amd_ntb_port_number(ntb);
> +
> + if (pidx > NTB_PIDX_MAX)
> + return -EINVAL;

pidx may be negative.

> +
> + return (local_port == NTB_PORT_PRI_USD ?
> + NTB_PORT_SEC_DSD : NTB_PORT_PRI_USD);

local_port may be -EINVAL.

It may be simpler to have the same switch statement here as in 
amd_ntb_port_number(), with the return statements swapped.

> +}
> +
> +static int amd_ntb_peer_port_idx(struct ntb_dev *ntb, int port)
> +{
> + int local_port = amd_ntb_port_number(ntb);
> +
> + if ((local_port == NTB_PORT_PRI_USD && port != NTB_PORT_SEC_DSD) ||
> + (local_port == NTB_PORT_SEC_DSD && port != NTB_PORT_PRI_USD))
> + return -EINVAL;
> +

How about:

peer_port = amd_ntb_peer_port_number(ntb, 0);

if (peer_port == -EINVAL || port != peer_port)
return -EINVAL;

return 0;

> + return 0;
> +}
> +
>  static int amd_link_is_up(struct amd_ntb_dev *ndev)
>  {
>   if (!ndev->peer_sta)
> @@ -431,6 +474,10 @@ static int amd_ntb_peer_spad_write(struct ntb_dev *ntb,
>  }
> 
>  static const struct ntb_dev_ops amd_ntb_ops = {
> + .port_number= amd_ntb_port_number,
> + .peer_port_count= amd_ntb_peer_port_count,
> + .peer_port_number   = amd_ntb_peer_port_number,
> + .peer_port_idx  = amd_ntb_peer_port_idx,
>   .link_is_up = amd_ntb_link_is_up,
>   .link_enable= amd_ntb_link_enable,
>   .link_disable   = amd_ntb_link_disable,
> diff --git a/drivers/ntb/hw/amd/ntb_hw_amd.h b/drivers/ntb/hw/amd/ntb_hw_amd.h
> index 2eac3cd..1aeb08f 100644
> --- a/drivers/ntb/hw/amd/ntb_hw_amd.h
> +++ b/drivers/ntb/hw/amd/ntb_hw_amd.h
> @@ -62,6 +62,10 @@
>  #define NTB_LNK_STA_SPEED(x) (((x) & NTB_LNK_STA_SPEED_MASK) >> 16)
>  #define NTB_LNK_STA_WIDTH(x) (((x) & NTB_LNK_STA_WIDTH_MASK) >> 20)
> 
> +/* port related constants */
> +#define NTB_PEER_CNT (1)
> +#define NTB_PIDX_MAX (0)

Just NTB_PEER_CNT is sufficient.  Anything that checks if (pidx > NTB_PIDX_MAX) 
could check if (pidx >= NTB_PEER_CNT).

> +
>  #ifndef read64
>  #ifdef readq
>  #define read64 readq
> @@ -91,6 +95,11 @@ static inline void _write64(u64 val, void __iomem *mmio)
>  #endif
>  #endif
> 
> +enum amd_ntb_port {
> + NTB_PORT_PRI_USD,
> + NTB_PORT_SEC_DSD
> +};

This could be part of ntb.h, since it will likely be the same for any of the 
PRI/SEC variety of NTB devices.  Making it a part of the api will 

Re: [PATCH 0/8] Sparse warning fixes in Lustre.

2016-12-12 Thread Oleg Drokin

On Dec 7, 2016, at 6:46 PM, Al Viro wrote:

> On Wed, Dec 07, 2016 at 05:41:26PM -0500, Oleg Drokin wrote:
>> This set of fixes aims at sparse warnings.
> 
> Speaking of the stuff sparse catches there: class_process_proc_param().
> I've tried to describe what I think of that Fine Piece Of Software
> several times, but I had to give up - my command of obscenity is not
> up to the task, neither in English nor in Russian.  Please, take it
> out.  Preferably - along with the ->ldo_process_config()/->process_config()
> thing.

Well, I can guess what you don't like in the remnants of the
"well, we have uniform procfs, so let's use that to our advantage and simplify
or config parsing".

But what's your beef with ldo_process_config()/->process_config(), I wonder?
Just a way to propagate config info across the layers.




RE: [RFC PATCH 0/4] KVM: Emulate UMIP (or almost do so)

2016-12-12 Thread Li, Liang Z
> UMIP (User-Mode Instruction Prevention) is a feature of future Intel
> processors (Cannonlake?) that blocks SLDT, SGDT, STR, SIDT and SMSW from
> user-mode processes.
> 
> The idea here is to use virtualization intercepts to emulate UMIP; it slows
> down the instructions when they're executed in ring 0, but they are really
> never executed in practice.  On AMD systems it's possible to emulate it
> entirely; instead on Intel systems it's *almost* possible to emulate it,
> because SMSW doesn't cause a vmexit, and hence SMSW will not fault.
> 
> This patch series provides the infrastructure and implements it on Intel.  I
> tested it through kvm-unit-tests.
> 
> Still I think the idea is interesting, even if it's buggy for current Intel
> processors.  Any opinions?

Hi Paolo,

We intended to enable UMIP for KVM and found you had already worked on it. 
Do you have any plan for the following patch set? It's there anything else you 
expect
us help to do?

Thanks!
Liang


[PATCH V2] doc: add note on usleep_range range

2016-12-12 Thread Nicholas Mc Guire
useleep_range() with a delta of 0 makes no sense and only prevents the
timer subsystem from optimizing interrupts. As any user of usleep_range()
is in non-atomic context the timer jitter is in the range of 10s of 
microseconds anyway.

This adds a note making it clear that a range of 0 is a bad idea.

Signed-off-by: Nicholas Mc Guire <hof...@osadl.org>
---

V2: trailing whitespaces removed (sent the wrong file before...)

as of 4.9.0 there are about 20 cases of usleep_ranges() that have 
min==max and none of them really look like they are necessary, so 
it does seem like a relatively common misunderstanding worth
noting in the documentation.

Patch is against 4.9.0 (localversion-next is 20161212)

 Documentation/timers/timers-howto.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/timers/timers-howto.txt 
b/Documentation/timers/timers-howto.txt
index 038f8c7..b5cdf82 100644
--- a/Documentation/timers/timers-howto.txt
+++ b/Documentation/timers/timers-howto.txt
@@ -93,6 +93,13 @@ NON-ATOMIC CONTEXT:
tolerances here are very situation specific, thus it
is left to the caller to determine a reasonable range.
 
+   A range of 0, that is usleep_range(100,100) or the
+   like, do not make sense as this code is in a
+   non-atomic section and a system can not be expected
+   to have jitter 0. For any non-RT code any delta
+   less than 50 microseconds probably is only preventing
+   timer subsystem optimization but providing no benefit.
+
SLEEPING FOR LARGER MSECS ( 10ms+ )
* Use msleep or possibly msleep_interruptible
 
-- 
2.1.4



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

2016-12-12 Thread Ralf Baechle
On Sun, Dec 11, 2016 at 09:04:48AM +0800, kbuild test robot wrote:

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

Which binutils are you using with this compiler?

Thanks,

  Ralf


[PATCH] doc: add note on usleep_range range

2016-12-12 Thread Nicholas Mc Guire
useleep_range() with a delta of 0 makes no sense and only prevents the
timer subsystem from optimizing interrupts. As any user of usleep_range()
is in non-atomic context the timer jitter is in the range of 10s of 
microseconds anyway.

This adds a note making it clear that a range of 0 is a bad idea.

Signed-off-by: Nicholas Mc Guire <hof...@osadl.org>
---

as of 4.9.0 there are about 20 cases of usleep_ranges() that have 
min==max and none of them really look like they are necessary, so 
it does seem like a relatively common misunderstanding worth
noting in the documentation.

Patch is against 4.9.0 (localversion-next is 20161212)

 Documentation/timers/timers-howto.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/timers/timers-howto.txt 
b/Documentation/timers/timers-howto.txt
index 038f8c7..b5cdf82 100644
--- a/Documentation/timers/timers-howto.txt
+++ b/Documentation/timers/timers-howto.txt
@@ -93,6 +93,13 @@ NON-ATOMIC CONTEXT:
tolerances here are very situation specific, thus it
is left to the caller to determine a reasonable range.
 
+   A range of 0, that is usleep_range(100,100) or the 
+   like, do not make sense as this code is in a 
+   non-atomic section and a system can not be expected 
+   to have jitter 0. For any non-RT code any delta
+   less than 50 microseconds probably is only preventing
+   timer subsystem optimization but providing no benefit.
+
SLEEPING FOR LARGER MSECS ( 10ms+ )
* Use msleep or possibly msleep_interruptible
 
-- 
2.1.4



Re: [PATCH 1/2] crypto: asymmetric_keys: set error code on failure

2016-12-12 Thread Herbert Xu
On Tue, Dec 13, 2016 at 08:53:11AM +1100, James Morris wrote:
> On Mon, 12 Dec 2016, David Howells wrote:
> 
> > From: Pan Bian 
> > 
> > In function public_key_verify_signature(), returns variable ret on
> > error paths. When the call to kmalloc() fails, the value of ret is 0,
> > and it is not set to an errno before returning. This patch fixes the
> > bug.
> > 
> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188891
> > 
> > Signed-off-by: Pan Bian 
> > Signed-off-by: David Howells 
> > ---
> 
> These crypto patches should probably go via Herbert's tree.

OK but someone will need to post them to linux-crypto first.

I know the originals went that way but David's repost doesn't
seem to be in patchwork.

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


regression, 4.8.10 -> 4.9.0 totally fail on NUMA machine, ACPI issue?

2016-12-12 Thread Denys Fedoryshchenko

Hi,

Just attempted to upgrade from 4.8.10 to 4.9.10 with minimal kernel 
changes (oldconfig, but then attempted to add few options to solve 
problem (such as adding NR_CPUS and PCI options, didnt helped).
My filesystem are residing on USB drive, and USB where flash are located 
is not working, so i am able to get only early kernel messages over 
netconsole. Also this server is semi-production,

and remote, so i can't do much tests on it (only at night).

Hardware:
2x E5-2640 v3
Motherboard: S2600WTT
RAM: 384GB (not sure)

Here is diff of kernel messages:

--- x0c 2016-12-13 04:37:04.245892429 +0200
+++ x1c 2016-12-13 04:45:23.976088816 +0200
@@ -1,5 +1,5 @@
-version 4.8.10-build-0121 (root@dev) (gcc version 5.4.0 (Gentoo 5.4.0 
p1.0, pie-0.6.5) ) #10 SMP Thu Nov 24 01:05:28 UTC 2016
-line: BOOT_IMAGE=kernel panic=1 intel_idle.max_cstate=0 
processor.max_cstate=1
+version 4.9.0-build-0123 (root@dev) (gcc version 5.4.0 (Gentoo 5.4.0 
p1.0, pie-0.6.5) ) #3 SMP Tue Dec 13 02:07:57 UTC 2016
+line: BOOT_IMAGE=kernelup panic=1 intel_idle.max_cstate=0 
processor.max_cstate=1

 Supporting XSAVE feature 0x001: 'x87 floating point registers'
 Supporting XSAVE feature 0x002: 'SSE registers'
 Supporting XSAVE feature 0x004: 'AVX registers'
@@ -249,36 +249,36 @@
 INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
 ACPI (MADT) for SMP configuration information
 HPET id: 0x8086a701 base: 0xfed0
-144 Processors exceeds NR_CPUS limit of 64
-Allowing 64 CPUs, 32 hotplug CPUs
+Allowing 32 CPUs, 0 hotplug CPUs
 [mem 0x9000-0xfed1bfff] available for PCI devices
 refined-jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 
1910969940391419 ns

-NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:64 nr_node_ids:2
-Embedded 33 pages/cpu @882fbf60 s95320 r8192 d31656 u262144
+NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:32 nr_node_ids:2
+Embedded 33 pages/cpu @882fbfa0 s95512 r8192 d31464 u262144
 2 zonelists in Node order, mobility grouping on. Total pages: 99066449
 zone: Normal
-command line: BOOT_IMAGE=kernel panic=1 intel_idle.max_cstate=0 
processor.max_cstate=1
+command line: BOOT_IMAGE=kernelup panic=1 intel_idle.max_cstate=0 
processor.max_cstate=1

 individual max cpu contribution: 4096 bytes
-total cpu_extra contributions: 258048 bytes
+total cpu_extra contributions: 126976 bytes
 min size: 32768 bytes
-524288 bytes
-log buf free: 11976(36%)
+262144 bytes
+log buf free: 12212(37%)
 hash table entries: 4096 (order: 3, 32768 bytes)
-396163212K/402555824K available (9082K kernel code, 730K rwdata, 4528K 
rodata, 8024K init, 416K bss, 6392612K reserved, 0K cma-reserved)

-HWalign=64, Order=0-3, MinObjects=0, CPUs=64, Nodes=2
+396167976K/402555824K available (9238K kernel code, 746K rwdata, 4564K 
rodata, 8016K init, 416K bss, 6387848K reserved, 0K cma-reserved)

+HWalign=64, Order=0-3, MinObjects=0, CPUs=32, Nodes=2
 RCU implementation.
 adjustment of leaf fanout to 64.
-nr_irqs:1752 16
+restricting CPUs from NR_CPUS=64 to nr_cpu_ids=32.
+Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=32
+nr_irqs:1496 16
 colour VGA+ 80x25
 [tty0] enabled
 hpet: mask: 0x max_cycles: 0x, max_idle_ns: 
133484882848 ns

 Fast TSC calibration using PIT
-Detected 2593.948 MHz processor
-delay loop (skipped), value calculated using timer frequency.. 5187.89 
BogoMIPS (lpj=2593948)

-default: 65536 minimum: 512
-Core revision 20160422
+Detected 2593.955 MHz processor
+delay loop (skipped), value calculated using timer frequency.. 5187.91 
BogoMIPS (lpj=2593955)

+default: 32768 minimum: 301
+Core revision 20160831
 4 ACPI AML tables successfully acquired and loaded
-
 Framework initialized
 cache hash table entries: 67108864 (order: 17, 536870912 bytes)
 hash table entries: 33554432 (order: 16, 268435456 bytes)
@@ -293,246 +293,31 @@
 using mwait in idle threads
 level iTLB entries: 4KB 1024, 2MB 1024, 4MB 1024
 level dTLB entries: 4KB 1024, 2MB 1024, 4MB 1024, 1GB 4
-SMP alternatives memory: 32K (8288e000 - 82896000)
+SMP alternatives memory: 32K (8289 - 82898000)
 APIC(0) Converting physical 0 to logical package 0
 APIC(10) Converting physical 1 to logical package 1
-fast init done
-Max logical packages: 18
-APIC routing to physical flat.
-vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
-CPU0: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz (family: 0x6, model: 
0x3f, stepping: 0x2)
-Events: PEBS fmt2+, Haswell events, 16-deep LBR, full-width counters, 
Intel PMU driver.

-version: 3
-bit width: 48
-generic registers: 4
-value mask: 
-max period: 
-fixed-purpose events: 3
-event mask: 0007000f
-watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.
-Booting SMP configuration:
-node #0, CPUs: #1 #2 #3 #4 #5 #6 #7
-node #1, CPUs: #8 #9 #10 #11 #12 #13 #14 #15
-node #0, CPUs: #16 #17 #18 #19 #20 #21 #22 #23
-node #1, CPUs: #24 #25 #26 #27 #28 #29 #30 #31
-Booted up 2 nodes, 32 CPUs
-Total of 32 processors activated 

Re: [PATCH v2 2/2] dt-bindings: Add DT bindings info for FlexRM ring manager

2016-12-12 Thread Anup Patel
On Fri, Dec 9, 2016 at 11:31 PM, Rob Herring  wrote:
> On Fri, Dec 02, 2016 at 10:08:56AM +0530, Anup Patel wrote:
>> This patch adds device tree bindings document for the FlexRM
>> ring manager found on Broadcom iProc SoCs.
>>
>> Reviewed-by: Ray Jui 
>> Reviewed-by: Scott Branden 
>> Signed-off-by: Anup Patel 
>> ---
>>  .../bindings/mailbox/brcm,iproc-flexrm-mbox.txt| 60 
>> ++
>>  1 file changed, 60 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt 
>> b/Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt
>> new file mode 100644
>> index 000..e81f116
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt
>> @@ -0,0 +1,60 @@
>
> [...]
>
>> +Example:
>> +
>> +crypto_mbox: mbox@6700 {
>> + compatible = "brcm,flexrm-mbox";
>> + reg = <0x6700 0x20>;
>> + msi-parent = <_its 0x7f00>;
>> + #mbox-cells = <3>;
>> +};
>> +
>> +crypto_client {
>> + ...
>> + mboxes = <_mbox 0 0x1 0x>,
>> +  <_mbox 1 0x1 0x>,
>> +  <_mbox 16 0x1 0x>,
>> +  <_mbox 17 0x1 0x>,
>> +  <_mbox 30 0x1 0x>,
>> +  <_mbox 31 0x1 0x>;
>
> The FlexRM part looks fine. I still don't understand what this node is.
> Is this a h/w block or just a list of mailboxes? What determines the
> mailbox channel numbers here? I need to see what the complete node looks
> like.

The crypto_client is an example mailbox client for FlexRM mailbox.

The example shows that we have FlexRM ring manager providing
ring based programming interface to Crypto offload engine. The
Crypto offload engine driver is a mailbox client driver.

FlexRM mailbox requires 3 cells to specify each mailbox channel in
"mboxes" attribute of mailbox client DT node. The 1st cell is
mailbox channel number (or FlexRM ring number). Rest of the
cells are explained in bindings document.

Complete node would look something like below:

crypto_client {
 compatible = "brcm,iproc-spu2";
 mboxes = <_mbox 0 0x1 0x>,
 <_mbox 1 0x1 0x>,
 <_mbox 16 0x1 0x>,
 <_mbox 17 0x1 0x>,
 <_mbox 30 0x1 0x>,
 <_mbox 31 0x1 0x>;
};

The Crypto driver was recently submitted by Rob Rice.
Refer https://www.spinics.net/lists/kernel/msg2395306.html

Similar to Crypto offload engine, we also have RAID offload
engine. The RAID offload engine driver is also implemented
as mailbox client driver.

Regards,
Anup


Re: [PATCH] crypto: Make a few drivers depend on !VMAP_STACK

2016-12-12 Thread Herbert Xu
On Mon, Dec 12, 2016 at 12:55:20PM -0800, Andy Lutomirski wrote:
> Eric Biggers found several crypto drivers that point scatterlists at
> the stack.  These drivers should never load on x86, but, for future
> safety, make them depend on !VMAP_STACK.
> 
> No -stable backport should be needed as no released kernel
> configuration should be affected.
> 
> Reported-by: Eric Biggers 
> Signed-off-by: Andy Lutomirski 

Nack.  These drivers are all async and are never used with a
stack request.

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


Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

2016-12-12 Thread Herbert Xu
On Mon, Dec 12, 2016 at 10:34:10AM -0800, Andy Lutomirski wrote:
>
> Here's my status.
> 
> > drivers/crypto/bfin_crc.c:351
> > drivers/crypto/qce/sha.c:299
> > drivers/crypto/sahara.c:973,988
> > drivers/crypto/talitos.c:1910
> > drivers/crypto/qce/sha.c:325
> 
> I have a patch to make these depend on !VMAP_STACK.

Why? They're all marked as ASYNC AFAIK.

> I have a patch to convert this to, drumroll please:
> 
> priv->tx_tfm_mic = crypto_alloc_shash("michael_mic", 0,
>   CRYPTO_ALG_ASYNC);
> 
> Herbert, I'm at a loss as what a "shash" that's "ASYNC" even means.

Having 0 as type and CRYPTO_ALG_ASYNC as mask in general means
that we're requesting a sync algorithm (i.e., ASYNC bit off).

However, it is completely unnecessary for shash as they can never
be async.  So this could be changed to just ("michael_mic", 0, 0).

> > net/ceph/crypto.c:182
> 
> This:
> 
> size_t zero_padding = (0x10 - (src_len & 0x0f));
> 
> is an amazing line of code...
> 
> But this driver uses cbc and wants to do synchronous crypto, and I
> don't think that the crypto API supports real synchronous crypto using
> CBC, so I'm going to let someone else fix this.

It does through skcipher if you allocate with (0, CRYPTO_ALG_ASYNC).

I'll try to fix this.

> > net/rxrpc/rxkad.c:737,1000
> 
> Herbert, can you fix this?

Sure I'll take a look.

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


Re: [PATCH] vfio/pci: Support error recovery

2016-12-12 Thread Alex Williamson
On Tue, 13 Dec 2016 05:15:13 +0200
"Michael S. Tsirkin"  wrote:

> On Mon, Dec 12, 2016 at 03:43:13PM -0700, Alex Williamson wrote:
> > > So just don't do it then. Topology must match between host and guest,
> > > except maybe for the case of devices with host driver  (e.g. PF)
> > > which we might be able to synchronize against.  
> > 
> > We're talking about host kernel level handling here.  The host kernel
> > cannot defer the link reset to the user under the assumption that the
> > user is handling the devices in a very specific way.  The moment we do
> > that, we've lost.  
> 
> The way is same as baremetal though, so why not?

How do we know this?  What if the user is dpdk?  The kernel is
responsible for maintaining the integrity of the system and devices,
not the user.

> And if user doesn't do what's expected, we can
> do the full link reset on close.

That's exactly my point, if we're talking about multiple devices,
there's no guarantee that the close() for each is simultaneous.  If one
function is released before the other we cannot do a bus reset.  If
that device is then opened by another user before its sibling is
released, then we once again cannot perform a link reset.  I don't
think it would be reasonable to mark the released device quarantined
until the sibling is released, that would be a terrible user experience.


Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

2016-12-12 Thread Herbert Xu
On Mon, Dec 12, 2016 at 12:45:18PM -0600, Gary R Hook wrote:
> On 12/12/2016 12:34 PM, Andy Lutomirski wrote:
> 
> <...snip...>
> 
> >
> >I have a patch to make these depend on !VMAP_STACK.
> >
> >>drivers/crypto/ccp/ccp-crypto-aes-cmac.c:105,119,142
> >>drivers/crypto/ccp/ccp-crypto-sha.c:95,109,124
> >>drivers/crypto/ccp/ccp-crypto-aes-xts.c:162
> >>drivers/crypto/ccp/ccp-crypto-aes.c:94
> >
> >According to Herbert, these are fine.  I'm personally less convinced
> >since I'm very confused as to what "async" means in the crypto code,
> >but I'm going to leave these alone.
> 
> I went back through the code, and AFAICT every argument to sg_init_one() in
> the above-cited files is a buffer that is part of the request context. Which
> is allocated by the crypto framework, and therefore will never be on the
> stack.
> Right?

Right.

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


Re: [PATCH v6 2/2] crypto: add virtio-crypto driver

2016-12-12 Thread Herbert Xu
On Tue, Dec 13, 2016 at 12:05:19AM +0200, Michael S. Tsirkin wrote:
>
> > Sorry but it's too late for 4.10.  It needed to have been in my
> > tree before the merge window opened to make it for this cycle.
> 
> Objections to me merging this? I'm preparing my tree right now.

Sure feel free to merge it through your tree.

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


[PATCH] staging: Remove slicoss driver

2016-12-12 Thread Guenter Roeck
There is now a different driver for the slicoss devices in
drivers/net/ethernet/alacritech/. That driver supports the same PCI
device IDs as the driver in staging. Both drivers use the same
configuration symbol (CONFIG_SLICOSS), which causes build failures
for the staging driver. Presumably the driver in staging is obsolete
and can be removed.

Cc: Tobias Klauser 
Cc: David S. Miller 
Cc: Lino Sanfilippo 
Cc: Lior Dotan 
Cc: Christopher Harrer 
Signed-off-by: Guenter Roeck 
---
 MAINTAINERS   |6 -
 drivers/staging/Kconfig   |2 -
 drivers/staging/Makefile  |1 -
 drivers/staging/slicoss/Kconfig   |   14 -
 drivers/staging/slicoss/Makefile  |1 -
 drivers/staging/slicoss/README|7 -
 drivers/staging/slicoss/TODO  |   36 -
 drivers/staging/slicoss/slic.h|  573 ---
 drivers/staging/slicoss/slichw.h  |  652 
 drivers/staging/slicoss/slicoss.c | 3131 -
 10 files changed, 4423 deletions(-)
 delete mode 100644 drivers/staging/slicoss/Kconfig
 delete mode 100644 drivers/staging/slicoss/Makefile
 delete mode 100644 drivers/staging/slicoss/README
 delete mode 100644 drivers/staging/slicoss/TODO
 delete mode 100644 drivers/staging/slicoss/slic.h
 delete mode 100644 drivers/staging/slicoss/slichw.h
 delete mode 100644 drivers/staging/slicoss/slicoss.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 4e62a0e67df9..75ec36ead16e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11549,12 +11549,6 @@ L: linux-fb...@vger.kernel.org
 S: Maintained
 F: drivers/staging/sm750fb/
 
-STAGING - SLICOSS
-M: Lior Dotan 
-M: Christopher Harrer 
-S: Odd Fixes
-F: drivers/staging/slicoss/
-
 STAGING - SPEAKUP CONSOLE SPEECH DRIVER
 M: William Hubbs 
 M: Chris Brannon 
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 58a7b3504b82..cd005cd41413 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -24,8 +24,6 @@ menuconfig STAGING
 
 if STAGING
 
-source "drivers/staging/slicoss/Kconfig"
-
 source "drivers/staging/wlan-ng/Kconfig"
 
 source "drivers/staging/comedi/Kconfig"
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 2fa9745db614..82328dc4e626 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -1,7 +1,6 @@
 # Makefile for staging directory
 
 obj-y  += media/
-obj-$(CONFIG_SLICOSS)  += slicoss/
 obj-$(CONFIG_PRISM2_USB)   += wlan-ng/
 obj-$(CONFIG_COMEDI)   += comedi/
 obj-$(CONFIG_FB_OLPC_DCON) += olpc_dcon/
diff --git a/drivers/staging/slicoss/Kconfig b/drivers/staging/slicoss/Kconfig
deleted file mode 100644
index 5c2a15b42dfe..
--- a/drivers/staging/slicoss/Kconfig
+++ /dev/null
@@ -1,14 +0,0 @@
-config SLICOSS
-   tristate "Alacritech Gigabit IS-NIC support"
-   depends on PCI && X86 && NET
-   default n
-   help
- This driver supports Alacritech's IS-NIC gigabit ethernet cards.
-
- This includes the following devices:
-   Mojave cards (single port PCI Gigabit) both copper and fiber
-   Oasis cards (single and dual port PCI-x Gigabit) copper and fiber
-   Kalahari cards (dual and quad port PCI-e Gigabit) copper and fiber
-
- To compile this driver as a module, choose M here: the module
- will be called slicoss.
diff --git a/drivers/staging/slicoss/Makefile b/drivers/staging/slicoss/Makefile
deleted file mode 100644
index 7bc9e9b9d3ab..
--- a/drivers/staging/slicoss/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-obj-$(CONFIG_SLICOSS) += slicoss.o
diff --git a/drivers/staging/slicoss/README b/drivers/staging/slicoss/README
deleted file mode 100644
index 4fa50e73ce86..
--- a/drivers/staging/slicoss/README
+++ /dev/null
@@ -1,7 +0,0 @@
-This driver is supposed to support:
-
-   Mojave cards (single port PCI Gigabit) both copper and fiber
-   Oasis cards (single and dual port PCI-x Gigabit) copper and fiber
-   Kalahari cards (dual and quad port PCI-e Gigabit) copper and fiber
-
-The driver was actually tested on Oasis and Kalahari cards.
diff --git a/drivers/staging/slicoss/TODO b/drivers/staging/slicoss/TODO
deleted file mode 100644
index 9019729b7be6..
--- a/drivers/staging/slicoss/TODO
+++ /dev/null
@@ -1,36 +0,0 @@
-TODO:
-   - move firmware loading to request_firmware()
-   - remove direct memory access of structures
-   - any remaining sparse and checkpatch.pl warnings
-
-   - use net_device_ops
-   - use dev->stats rather than adapter->stats
-   - don't cast netdev_priv it is already void
-   - GET RID OF MACROS
-   - work on all architectures
-  - without CONFIG_X86_64 confusion
-  

Re: [PATCH v6] pwm: add pwm driver for HiSilicon BVT SOCs

2016-12-12 Thread Jian Yuan
Hi, Thierry,
  Are there any issues with the PWM driver below.
  I would like to request some comment and advice form you, if you had reviewed 
the driver code.

  With best wishes,
  Jian Yuan

On 2016/11/28 17:42, Jian Yuan wrote:
> From: yuanjian 
> 
> Add PWM driver for the PWM controller found on HiSilicon BVT SOCs, like 
> Hi3519V100, Hi3516CV300, etc.
> The PWM controller is primarily in charge of controlling P-Iris lens.
> 
> Reviewed-by: Jiancheng Xue 
> Signed-off-by: Jian Yuan 
> ---
> Acked-by: Rob Herring 
> 
> Change Log:
> v6:
> It supports polarity specified in DTB and #pwm-cells can be set to 3.
> v5:
> remove the generic compatible string "hisilicon, hibvt-pwm".
> v4:
> Add #pwm-cells in the bindings document.
> v3:
> fixed issues pointed by thierry.
> Add PWM compatible string for Hi3519V100.
> Implement .apply() function which support atomic, instead of 
> .enable()/.disable()/.config().
> v2:
> The number of PWMs is change to be probeable based on the compatible string.
> 
>  .../devicetree/bindings/pwm/pwm-hibvt.txt  |  22 ++
>  drivers/pwm/Kconfig|   9 +
>  drivers/pwm/Makefile   |   1 +
>  drivers/pwm/pwm-hibvt.c| 271 
> +
>  4 files changed, 302 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-hibvt.txt
>  create mode 100644 drivers/pwm/pwm-hibvt.c
> 
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-hibvt.txt 
> b/Documentation/devicetree/bindings/pwm/pwm-hibvt.txt
> new file mode 100644
> index 000..fa7849d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-hibvt.txt
> @@ -0,0 +1,21 @@
> +Hisilicon PWM controller
> +
> +Required properties:
> +-compatible: should contain one SoC specific compatible string
> + The SoC specific strings supported including:
> + "hisilicon,hi3516cv300-pwm"
> + "hisilicon,hi3519v100-pwm"
> +- reg: physical base address and length of the controller's registers.
> +- clocks: phandle and clock specifier of the PWM reference clock.
> +- resets: phandle and reset specifier for the PWM controller reset.
> +- #pwm-cells: Should be 3. See pwm.txt in this directory for a description of
> +  the cells format.
> +
> +Example:
> + pwm: pwm@1213 {
> + compatible = "hisilicon,hi3516cv300-pwm";
> + reg = <0x1213 0x1>;
> + clocks = <_ctrl HI3516CV300_PWM_CLK>;
> + resets = <_ctrl 0x38 0>;
> + #pwm-cells = <3>;
> + };
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index c182efc..b2d7408 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -158,6 +158,15 @@ config PWM_FSL_FTM
> To compile this driver as a module, choose M here: the module
> will be called pwm-fsl-ftm.
>  
> +config PWM_HIBVT
> + tristate "HiSilicon BVT PWM support"
> + depends on ARCH_HISI || COMPILE_TEST
> + help
> +   Generic PWM framework driver for HiSilicon BVT SoCs.
> +
> +   To compile this driver as a module, choose M here: the module
> +   will be called pwm-hibvt.
> +
>  config PWM_IMG
>   tristate "Imagination Technologies PWM driver"
>   depends on HAS_IOMEM
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index dd35bc1..37ec39e 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -13,6 +13,7 @@ obj-$(CONFIG_PWM_CLPS711X)  += pwm-clps711x.o
>  obj-$(CONFIG_PWM_CRC)+= pwm-crc.o
>  obj-$(CONFIG_PWM_EP93XX) += pwm-ep93xx.o
>  obj-$(CONFIG_PWM_FSL_FTM)+= pwm-fsl-ftm.o
> +obj-$(CONFIG_PWM_HIBVT)  += pwm-hibvt.o
>  obj-$(CONFIG_PWM_IMG)+= pwm-img.o
>  obj-$(CONFIG_PWM_IMX)+= pwm-imx.o
>  obj-$(CONFIG_PWM_JZ4740) += pwm-jz4740.o
> diff --git a/drivers/pwm/pwm-hibvt.c b/drivers/pwm/pwm-hibvt.c
> new file mode 100644
> index 000..d0e8f85
> --- /dev/null
> +++ b/drivers/pwm/pwm-hibvt.c
> @@ -0,0 +1,271 @@
> +/*
> + * PWM Controller Driver for HiSilicon BVT SoCs
> + *
> + * Copyright (c) 2016 HiSilicon Technologies Co., Ltd.
> + *
> + * 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.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> 

Re: [PATCH] selftests: ftrace: Shift down default message verbosity

2016-12-12 Thread Masami Hiramatsu
Ping?

On Fri, 25 Nov 2016 21:58:48 +0900
Masami Hiramatsu  wrote:

> Shift down default message verbosity, so that do not show
> error results in stdout by default. Since that behavior
> is same as giving --quiet option, this patch removes
> --quiet and make --verbose increasing verbosity.
> 
> In other words, this changes verbosity options as below.
> ftracetest -q -> ftracetest
> ftracetest-> ftracetest -v
> ftracetest -v -> ftracetest -v -v (or -vv)
> 
> Signed-off-by: Masami Hiramatsu 
> ---
>  tools/testing/selftests/ftrace/ftracetest |   18 +++---
>  1 file changed, 7 insertions(+), 11 deletions(-)
> 
> diff --git a/tools/testing/selftests/ftrace/ftracetest 
> b/tools/testing/selftests/ftrace/ftracetest
> index 685376b4..52e3c4d 100755
> --- a/tools/testing/selftests/ftrace/ftracetest
> +++ b/tools/testing/selftests/ftrace/ftracetest
> @@ -13,8 +13,8 @@ echo "Usage: ftracetest [options] [testcase(s)] 
> [testcase-directory(s)]"
>  echo " Options:"
>  echo "   -h|--help  Show help message"
>  echo "   -k|--keep  Keep passed test logs"
> -echo "   -v|--verbose Show all stdout messages in testcases"
> -echo "   -q|--quiet Do not show error log on stdout"
> +echo "   -v|--verbose Increase verbosity of test messages"
> +echo "   -vvAlias of -v -v (Show all results in stdout)"
>  echo "   -d|--debug Debug mode (trace all shell commands)"
>  exit $1
>  }
> @@ -55,12 +55,9 @@ parse_opts() { # opts
>KEEP_LOG=1
>shift 1
>  ;;
> ---verbose|-v)
> -  VERBOSE=1
> -  shift 1
> -;;
> ---quiet|-q)
> -  BE_QUIET=1
> +--verbose|-v|-vv)
> +  VERBOSE=$((VERBOSE + 1))
> +  [ $1 == '-vv' ] && VERBOSE=$((VERBOSE + 1))
>shift 1
>  ;;
>  --debug|-d)
> @@ -106,7 +103,6 @@ LOG_DIR=$TOP_DIR/logs/`date +%Y%m%d-%H%M%S`/
>  KEEP_LOG=0
>  DEBUG=0
>  VERBOSE=0
> -BE_QUIET=0
>  # Parse command-line options
>  parse_opts $*
>  
> @@ -246,7 +242,7 @@ run_test() { # testfile
>testcase $1
>echo "execute: "$1 > $testlog
>SIG_RESULT=0
> -  if [ $VERBOSE -ne 0 ]; then
> +  if [ $VERBOSE -ge 2 ]; then
>  __run_test $1 2>> $testlog | tee -a $testlog
>else
>  __run_test $1 >> $testlog 2>&1
> @@ -256,7 +252,7 @@ run_test() { # testfile
>  # Remove test log if the test was done as it was expected.
>  [ $KEEP_LOG -eq 0 ] && rm $testlog
>else
> -[ $BE_QUIET -eq 0 ] && catlog $testlog
> +[ $VERBOSE -ge 1 ] && catlog $testlog
>  TOTAL_RESULT=1
>fi
>rm -rf $TMPDIR
> 


-- 
Masami Hiramatsu


Re: [PATCH 2/2] usb: host: xhci: Handle the right timeout command

2016-12-12 Thread Baolin Wang
Hi Mathias,

On 12 December 2016 at 23:52, Mathias Nyman
 wrote:
> On 05.12.2016 09:51, Baolin Wang wrote:
>>
>> If a command event is found on the event ring during an interrupt,
>> we need to stop the command timer with del_timer(). Since del_timer()
>> can fail if the timer is running and waiting on the xHCI lock, then
>> it maybe get the wrong timeout command in xhci_handle_command_timeout()
>> if host fetched a new command and updated the xhci->current_cmd in
>> handle_cmd_completion(). For this situation, we need a way to signal
>> to the command timer that everything is fine and it should exit.
>
>
> Ah, right, this could actually happen.
>
>>
>>
>> We should introduce a counter (xhci->current_cmd_pending) for the number
>> of pending commands. If we need to cancel the command timer and
>> del_timer()
>> succeeds, we decrement the number of pending commands. If del_timer()
>> fails,
>> we leave the number of pending commands alone.
>>
>> For handling timeout command, in xhci_handle_command_timeout() we will
>> check
>> the counter after decrementing it, if the counter
>> (xhci->current_cmd_pending)
>> is 0, which means xhci->current_cmd is the right timeout command. If the
>> counter (xhci->current_cmd_pending) is greater than 0, which means current
>> timeout command has been handled by host and host has fetched new command
>> as
>> xhci->current_cmd, then just return and wait for new current command.
>
>
> A counter like this could work.
>
> Writing the abort bit can generate either ABORT+STOP, or just STOP
> event, this seems to cover both.
>
> quick check, case 1: timeout and cmd completion at the same time.
>
> cpu1cpu2
>
> queue_command(first), p++ (=1)
> queue_command(more),
> --completion irq fires---- timer times out at same time--
> handle_cmd_completion() handle_cmd_timeout(),)
> lock(xhci_lock  )   spin_on(xhci_lock)
> del_timer() fail, p (=1, nochange)
> cur_cmd = list_next(), p++ (=2)
> unlock(xhci_lock)
> lock(xhci_lock)
> p-- (=1)
> if (p > 0), exit
> OK works
>
> case 2: normal timeout case with ABORT+STOP, no race.
>
> cpu1cpu2
>
> queue_command(first), p++ (=1)
> queue_command(more),
> handle_cmd_timeout()
> p-- (P=0), don't exit
> mod_timer(), p++ (P=1)
> write_abort_bit()
> handle_cmd_comletion(ABORT)
> del_timer(), ok, p-- (p = 0)
> handle_cmd_completion(STOP)
> del_timer(), fail, (P=0)
> handle_stopped_cmd_ring()
> cur_cmd = list_next(), p++ (=1)
> mod_timer()
>
> OK, works, and same for just STOP case, with the only difference that
> during handle_cmd_completion(STOP) p is decremented (p--)

Yes, that's the cases what I want to handle, thanks for your explicit
explanation.

>
> So unless there is a way to find out if cur_cmd is valid in command timeout
> in command timeout with the help of existing flags and lists this would be a
> working
> solution.
>
> -Mathias
>



-- 
Baolin.wang
Best Regards


Re: [PATCH] Fix multiple definition error under lto

2016-12-12 Thread Eduardo Valentin
On Mon, Dec 12, 2016 at 11:45:06AM +0800, Zhang Rui wrote:
> On Sat, 2016-11-26 at 17:25 -0500, Peter Foley wrote:
> > drivers/thermal/built-in.o: In function `type_show.lto_priv.33':
> > (.text+0x3d80): multiple definition of `type_show.lto_priv.33'
> > drivers/base/built-in.o:(.text+0x2a40): first defined here
> > 
> can you illustrate how to reproduce this problem?

same here. I am not able to see this. Can you please describe your
environment?



Re: [PATCH] vfio/pci: Support error recovery

2016-12-12 Thread Michael S. Tsirkin
On Mon, Dec 12, 2016 at 03:43:13PM -0700, Alex Williamson wrote:
> > So just don't do it then. Topology must match between host and guest,
> > except maybe for the case of devices with host driver  (e.g. PF)
> > which we might be able to synchronize against.
> 
> We're talking about host kernel level handling here.  The host kernel
> cannot defer the link reset to the user under the assumption that the
> user is handling the devices in a very specific way.  The moment we do
> that, we've lost.

The way is same as baremetal though, so why not?

And if user doesn't do what's expected, we can
do the full link reset on close.

-- 
MST


[PATCH 5/5] firmware: add DECLARE_FW_CUSTOM_FALLBACK() annotation

2016-12-12 Thread Luis R. Rodriguez
We need to ensure that when driver developers use the custom firmware
fallback mechanism it was not a copy and paste bug. These use cases on
upstream drivers are rare, we only have 2 upstream users and its for
really old drivers. Since valid uses are rare but possible enable a
white-list for its use, and use this same white-list annotation to refer
to the documentation covering the custom use case.

New faulty users can be reported via 0-day now.

Cc: Fengguang Wu 
Cc: Richard Purdie 
Cc: Jacek Anaszewski 
Cc: linux-l...@vger.kernel.org
Cc: Abhay Salunke 
Signed-off-by: Luis R. Rodriguez 
---
 Documentation/driver-api/firmware/fallback-mechanisms.rst | 7 +--
 drivers/firmware/dell_rbu.c   | 1 +
 drivers/leds/leds-lp55xx-common.c | 1 +
 include/linux/firmware.h  | 7 +++
 scripts/coccinelle/api/request_firmware-custom-fallback.cocci | 9 -
 5 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst 
b/Documentation/driver-api/firmware/fallback-mechanisms.rst
index 955c11d6ff9d..b51673e40439 100644
--- a/Documentation/driver-api/firmware/fallback-mechanisms.rst
+++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst
@@ -184,8 +184,11 @@ load firmware for you through a custom path.
 
 The custom fallback mechanism can often be enabled by mistake. We currently
 have only 2 users of it, and little justification to enable it for other users.
-Since it is a common driver developer mistake to enable it, help police for
-new users of the custom fallback mechanism with::
+Since it is a common driver developer mistake to enable it, driver developers
+should use DECLARE_FW_CUSTOM_FALLBACK() to both white-list and validate their
+use and also refer to the documentation for the custom loading solution.
+
+Invalid users of the custom fallback mechanism can be policed using::
 
 $ export 
COCCI=scripts/coccinelle/api/request_firmware-avoid-init-probe-init.cocci
 $ make coccicheck MODE=report
diff --git a/drivers/firmware/dell_rbu.c b/drivers/firmware/dell_rbu.c
index 2f452f1f7c8a..3f2aa35bc54d 100644
--- a/drivers/firmware/dell_rbu.c
+++ b/drivers/firmware/dell_rbu.c
@@ -586,6 +586,7 @@ static ssize_t read_rbu_image_type(struct file *filp, 
struct kobject *kobj,
return size;
 }
 
+DECLARE_FW_CUSTOM_FALLBACK("Documentation/dell_rbu.txt");
 static ssize_t write_rbu_image_type(struct file *filp, struct kobject *kobj,
struct bin_attribute *bin_attr,
char *buffer, loff_t pos, size_t count)
diff --git a/drivers/leds/leds-lp55xx-common.c 
b/drivers/leds/leds-lp55xx-common.c
index 5377f22ff994..04161428ee3b 100644
--- a/drivers/leds/leds-lp55xx-common.c
+++ b/drivers/leds/leds-lp55xx-common.c
@@ -219,6 +219,7 @@ static void lp55xx_firmware_loaded(const struct firmware 
*fw, void *context)
release_firmware(chip->fw);
 }
 
+DECLARE_FW_CUSTOM_FALLBACK("Documentation/leds/leds-lp55xx.txt");
 static int lp55xx_request_firmware(struct lp55xx_chip *chip)
 {
const char *name = chip->cl->name;
diff --git a/include/linux/firmware.h b/include/linux/firmware.h
index b1f9f0ccb8ac..e6ca19c03dcc 100644
--- a/include/linux/firmware.h
+++ b/include/linux/firmware.h
@@ -8,6 +8,13 @@
 #define FW_ACTION_NOHOTPLUG 0
 #define FW_ACTION_HOTPLUG 1
 
+/*
+ * Helper for scripts/coccinelle/api/request_firmware-custom-fallback.cocci
+ * and so users can also easily search for the documentation for the
+ * respectively needed custom fallback mechanism.
+ */
+#define DECLARE_FW_CUSTOM_FALLBACK(__usermode_helper)
+
 struct firmware {
size_t size;
const u8 *data;
diff --git a/scripts/coccinelle/api/request_firmware-custom-fallback.cocci 
b/scripts/coccinelle/api/request_firmware-custom-fallback.cocci
index c7598cfc4780..68cacab35b76 100644
--- a/scripts/coccinelle/api/request_firmware-custom-fallback.cocci
+++ b/scripts/coccinelle/api/request_firmware-custom-fallback.cocci
@@ -17,6 +17,13 @@
 virtual report
 virtual context
 
+@ r0 depends on report || context @
+declarer name DECLARE_FW_CUSTOM_FALLBACK;
+expression E;
+@@
+
+DECLARE_FW_CUSTOM_FALLBACK(E);
+
 @ r1 depends on report || context @
 expression mod, name, dev, gfp, drv, cb;
 position p;
@@ -30,7 +37,7 @@ position p;
 *request_firmware_nowait@p(mod, FW_ACTION_NOHOTPLUG, name, dev, gfp, drv, cb)
 )
 
-@script:python depends on report@
+@script:python depends on report && !r0 @
 p << r1.p;
 @@
 
-- 
2.10.1



[PATCH 4/5] firmware: add SmPL report for custom fallback mechanism

2016-12-12 Thread Luis R. Rodriguez
Even though most distributions today disable the fallback mechanism
by default we've determined that we cannot remove them from the kernel.
This is not well understood so document the reason and logic behind that.

Recent discussions suggest some future userspace development prospects which
may enable fallback mechanisms to become more useful while avoiding some
historical issues. These discussions have made it clear though that there
is less value to the custom fallback mechanism and an alternative can be
provided in the future. Its also clear that some old users of the custom
fallback mechanism were using it as a copy and paste error. Because of
all this add a Coccinelle SmPL patch to help maintainers police for new
incorrect users of the custom fallback mechanism.

Best we can do for now then is police for new users of the custom
fallback mechanism and and fix incorrect users when they are spotted.
Drivers can only be transitioned out of the custom fallback mechanism
once we know old userspace cannot be not be broken by a kernel change.

The current SmPL patch reports:

$ export COCCI=scripts/coccinelle/api/request_firmware-custom-fallback.cocci
$ make coccicheck MODE=report

drivers/leds/leds-lp55xx-common.c:227:8-31: WARNING: please check if driver 
really needs a custom fallback mechanism
drivers/firmware/dell_rbu.c:622:17-40: WARNING: please check if driver really 
needs a custom fallback mechanism

Cc: Richard Purdie 
Cc: Jacek Anaszewski 
Cc: linux-l...@vger.kernel.org
Cc: Abhay Salunke 
Signed-off-by: Luis R. Rodriguez 
---
 .../driver-api/firmware/fallback-mechanisms.rst| 17 ++
 .../api/request_firmware-custom-fallback.cocci | 37 ++
 2 files changed, 54 insertions(+)
 create mode 100644 
scripts/coccinelle/api/request_firmware-custom-fallback.cocci

diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst 
b/Documentation/driver-api/firmware/fallback-mechanisms.rst
index edce1d76ce29..955c11d6ff9d 100644
--- a/Documentation/driver-api/firmware/fallback-mechanisms.rst
+++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst
@@ -28,6 +28,12 @@ CONFIG_FW_LOADER_USER_HELPER_FALLBACK=n
 the kobject uevent fallback mechanism will never take effect even
 for request_firmware_nowait() when uevent is set to true.
 
+Although the fallback mechanisms are not used widely today they cannot be
+removed from the kernel since some old userspace may exist which could
+entirely depend on the fallback mechanism enabled with the kernel config option
+CONFIG_FW_LOADER_USER_HELPER_FALLBACK. In the future though drivers may opt
+to embrace a different API which provides alternative fallback mechanisms.
+
 Justifying the firmware fallback mechanism
 ==
 
@@ -176,6 +182,17 @@ but you want to suppress kobject uevents, as you have a 
custom solution which
 will monitor for your device addition into the device hierarchy somehow and
 load firmware for you through a custom path.
 
+The custom fallback mechanism can often be enabled by mistake. We currently
+have only 2 users of it, and little justification to enable it for other users.
+Since it is a common driver developer mistake to enable it, help police for
+new users of the custom fallback mechanism with::
+
+$ export 
COCCI=scripts/coccinelle/api/request_firmware-avoid-init-probe-init.cocci
+$ make coccicheck MODE=report
+
+Drivers can only be transitioned out of the custom fallback mechanism
+once we know old userspace cannot be not be broken by a kernel change.
+
 Firmware fallback timeout
 =
 
diff --git a/scripts/coccinelle/api/request_firmware-custom-fallback.cocci 
b/scripts/coccinelle/api/request_firmware-custom-fallback.cocci
new file mode 100644
index ..c7598cfc4780
--- /dev/null
+++ b/scripts/coccinelle/api/request_firmware-custom-fallback.cocci
@@ -0,0 +1,37 @@
+// Avoid the firmware custom fallback mechanism at all costs
+//
+// request_firmware_nowait() API enables explicit request for use of the custom
+// fallback mechanism if firmware is not found. Chances are high its use is
+// just a copy and paste bug. Before you fix the driver be sure to *verify* no
+// custom firmware loading tool exists that would otherwise break if we replace
+// the driver to use the uevent fallback mechanism.
+//
+// Confidence: High
+//
+// Reason for low confidence:
+//
+// Copyright: (C) 2016 Luis R. Rodriguez  GPLv2.
+//
+// Options: --include-headers
+
+virtual report
+virtual context
+
+@ r1 depends on report || context @
+expression mod, name, dev, gfp, drv, cb;
+position p;
+@@
+
+(
+*request_firmware_nowait@p(mod, false, name, dev, gfp, drv, cb)
+|
+*request_firmware_nowait@p(mod, 0, name, dev, gfp, drv, cb)
+|
+*request_firmware_nowait@p(mod, FW_ACTION_NOHOTPLUG, name, dev, gfp, drv, cb)
+)
+
+@script:python 

[PATCH 2/5] selftests: firmware: send expected errors to /dev/null

2016-12-12 Thread Luis R. Rodriguez
Error that we expect should not be spilled to stdout.

Without this we get:

./fw_filesystem.sh: line 58: printf: write error: Invalid argument
./fw_filesystem.sh: line 63: printf: write error: No such device
./fw_filesystem.sh: line 69: echo: write error: No such file or directory
./fw_filesystem.sh: filesystem loading works
./fw_filesystem.sh: async filesystem loading works

With it:

./fw_filesystem.sh: filesystem loading works
./fw_filesystem.sh: async filesystem loading works

Signed-off-by: Luis R. Rodriguez 
---
 tools/testing/selftests/firmware/fw_filesystem.sh | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/testing/selftests/firmware/fw_filesystem.sh 
b/tools/testing/selftests/firmware/fw_filesystem.sh
index c8ccdaa78479..e35691239350 100755
--- a/tools/testing/selftests/firmware/fw_filesystem.sh
+++ b/tools/testing/selftests/firmware/fw_filesystem.sh
@@ -63,18 +63,18 @@ echo "ABCD0123" >"$FW"
 
 NAME=$(basename "$FW")
 
-if printf '\000' >"$DIR"/trigger_request; then
+if printf '\000' >"$DIR"/trigger_request 2> /dev/null; then
echo "$0: empty filename should not succeed" >&2
exit 1
 fi
 
-if printf '\000' >"$DIR"/trigger_async_request; then
+if printf '\000' >"$DIR"/trigger_async_request 2> /dev/null; then
echo "$0: empty filename should not succeed (async)" >&2
exit 1
 fi
 
 # Request a firmware that doesn't exist, it should fail.
-if echo -n "nope-$NAME" >"$DIR"/trigger_request; then
+if echo -n "nope-$NAME" >"$DIR"/trigger_request 2> /dev/null; then
echo "$0: firmware shouldn't have loaded" >&2
exit 1
 fi
-- 
2.10.1



[PATCH 1/5] selftests: firmware: only modprobe if driver is missing

2016-12-12 Thread Luis R. Rodriguez
No need to load test_firmware if its already there.
Also use a more generic form to recommend what is required
to be built.

Signed-off-by: Luis R. Rodriguez 
---
 tools/testing/selftests/firmware/fw_filesystem.sh | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/firmware/fw_filesystem.sh 
b/tools/testing/selftests/firmware/fw_filesystem.sh
index 5c495ad7958a..c8ccdaa78479 100755
--- a/tools/testing/selftests/firmware/fw_filesystem.sh
+++ b/tools/testing/selftests/firmware/fw_filesystem.sh
@@ -5,9 +5,24 @@
 # know so we can be sure we're not accidentally testing the user helper.
 set -e
 
-modprobe test_firmware
-
 DIR=/sys/devices/virtual/misc/test_firmware
+TEST_DIR=$(dirname $0)
+
+test_modprobe()
+{
+   if [ ! -d $DIR ]; then
+   echo "$0: $DIR not present"
+   echo "You must have the following enabled in your kernel:"
+   cat $TEST_DIR/config
+   exit 1
+   fi
+}
+
+trap "test_modprobe" EXIT
+
+if [ ! -d $DIR ]; then
+   modprobe test_firmware
+fi
 
 # CONFIG_FW_LOADER_USER_HELPER has a sysfs class under /sys/class/firmware/
 # These days no one enables CONFIG_FW_LOADER_USER_HELPER so check for that
-- 
2.10.1



[PATCH 3/5] firmware: revamp firmware documentation

2016-12-12 Thread Luis R. Rodriguez
Understanding this code is getting out of control without any
notes. Give the firmware_class driver a much needed documentation love,
and while at it convert it to the new sphinx documentation format.

Signed-off-by: Luis R. Rodriguez 
---
 Documentation/driver-api/firmware/built-in-fw.rst  |  36 
 Documentation/driver-api/firmware/core.rst |  16 ++
 .../driver-api/firmware/direct-fs-lookup.rst   |  30 
 .../driver-api/firmware/fallback-mechanisms.rst| 195 +
 .../driver-api/firmware/firmware_cache.rst |  51 ++
 .../driver-api/firmware/fw_search_path.rst |  26 +++
 Documentation/driver-api/firmware/index.rst|  16 ++
 Documentation/driver-api/firmware/introduction.rst |  27 +++
 Documentation/driver-api/firmware/lookup-order.rst |  18 ++
 .../driver-api/firmware/request_firmware.rst   |  56 ++
 Documentation/driver-api/index.rst |   1 +
 Documentation/firmware_class/README| 128 --
 12 files changed, 472 insertions(+), 128 deletions(-)
 create mode 100644 Documentation/driver-api/firmware/built-in-fw.rst
 create mode 100644 Documentation/driver-api/firmware/core.rst
 create mode 100644 Documentation/driver-api/firmware/direct-fs-lookup.rst
 create mode 100644 Documentation/driver-api/firmware/fallback-mechanisms.rst
 create mode 100644 Documentation/driver-api/firmware/firmware_cache.rst
 create mode 100644 Documentation/driver-api/firmware/fw_search_path.rst
 create mode 100644 Documentation/driver-api/firmware/index.rst
 create mode 100644 Documentation/driver-api/firmware/introduction.rst
 create mode 100644 Documentation/driver-api/firmware/lookup-order.rst
 create mode 100644 Documentation/driver-api/firmware/request_firmware.rst
 delete mode 100644 Documentation/firmware_class/README

diff --git a/Documentation/driver-api/firmware/built-in-fw.rst 
b/Documentation/driver-api/firmware/built-in-fw.rst
new file mode 100644
index ..382e1578a693
--- /dev/null
+++ b/Documentation/driver-api/firmware/built-in-fw.rst
@@ -0,0 +1,36 @@
+=
+Built-in firmware
+=
+
+Firmware can be built-in to the kernel, that is built-in to vmlinux,
+to enable firmware lookups to avoid having to look for firmware from
+the filesystem. You can enable built-in firmware using the kernel
+configuration options:
+
+  * CONFIG_EXTRA_FIRMWARE
+  * CONFIG_EXTRA_FIRMWARE_DIR
+
+The should not be confused with CONFIG_FIRMWARE_IN_KERNEL, this is for drivers
+which enable firmware to be built as part of the kernel build process. This
+option, CONFIG_FIRMWARE_IN_KERNEL, will build all firmware for all drivers
+enabled which ship its firmware inside the Linux kernel source tree.
+
+There are a few reasons why you might want to consider building your firmware
+into the kernel with CONFIG_EXTRA_FIRMWARE though:
+
+* Speed
+* Firmware is needed for accessing the boot device, and the user doesn't
+  want to stuff the firmware into the boot initramfs.
+
+Even if you have these needs there are a few reasons why you may not be
+able to make use of built-in firmware:
+
+* Legalese - firmware is non-GPL compatible
+* Some firmware may be optional
+* Firmware upgrades are possible, therefore a new firmware would implicate
+  a complete firmware rebuild.
+* Some firmware files may be really large in size. The remote-proc subsystem
+  is an example subsystem which deals with these sorts of firmware
+* The firmware may need to be scraped out from some device specific location
+  dynamically, an example is calibration data for for some WiFi chipsets.
+
diff --git a/Documentation/driver-api/firmware/core.rst 
b/Documentation/driver-api/firmware/core.rst
new file mode 100644
index ..1d1688cbc078
--- /dev/null
+++ b/Documentation/driver-api/firmware/core.rst
@@ -0,0 +1,16 @@
+==
+Firmware API core features
+==
+
+The firmware API has a rich set of core features available. This section
+documents these features.
+
+.. toctree::
+
+   fw_search_path
+   built-in-fw
+   firmware_cache
+   direct-fs-lookup
+   fallback-mechanisms
+   lookup-order
+
diff --git a/Documentation/driver-api/firmware/direct-fs-lookup.rst 
b/Documentation/driver-api/firmware/direct-fs-lookup.rst
new file mode 100644
index ..82b4d585a213
--- /dev/null
+++ b/Documentation/driver-api/firmware/direct-fs-lookup.rst
@@ -0,0 +1,30 @@
+
+Direct filesystem lookup
+
+
+Direct filesystem lookup is the most common form of firmware lookup performed
+by the kernel. The kernel looks for the firmware directly on the root
+filesystem in the paths documented in the section 'Firmware search paths'.
+The filesystem lookup is implemented in fw_get_filesystem_firmware(), it
+uses common core kernel file loader facility kernel_read_file_from_path().
+The max path allowed is PATH_MAX -- currently this is 4096 

[PATCH 0/5] firmware: doc revamp

2016-12-12 Thread Luis R. Rodriguez
Greg,

here's a few simple changes for documentation revamp and a few
simple fixes for the firmware test script. I'm pretty sure this is
too late for the next release so I am happy with this getting queued in
until the merge window closes, posting now to iron out kinks once
the merge window closes.

I'll soon also post the extensible firmware API as per feedback, much of
which was just name change preferences and also a huge clarification on
roadmap on fallback mechanisms. The documentation should help iron out
tons of kinks I think folks have on this front, but more on all this later
once those patches get posted.

You may notice I've dropped the SmPL patches which complain on use of the
API on init and probe -- although valid the context was off given the only
valid use case was if you don't use initramfs, and that's a corner case.
Fortunatley Daniel Wagner and Tom Gundersen have come up with some ideas
that should help correct these issues, so I've dropped that grammar patch.

Luis R. Rodriguez (5):
  selftests: firmware: only modprobe if driver is missing
  selftests: firmware: send expected errors to /dev/null
  firmware: revamp firmware documentation
  firmware: add SmPL report for custom fallback mechanism
  firmware: add DECLARE_FW_CUSTOM_FALLBACK() annotation

 Documentation/driver-api/firmware/built-in-fw.rst  |  36 
 Documentation/driver-api/firmware/core.rst |  16 ++
 .../driver-api/firmware/direct-fs-lookup.rst   |  30 +++
 .../driver-api/firmware/fallback-mechanisms.rst| 215 +
 .../driver-api/firmware/firmware_cache.rst |  51 +
 .../driver-api/firmware/fw_search_path.rst |  26 +++
 Documentation/driver-api/firmware/index.rst|  16 ++
 Documentation/driver-api/firmware/introduction.rst |  27 +++
 Documentation/driver-api/firmware/lookup-order.rst |  18 ++
 .../driver-api/firmware/request_firmware.rst   |  56 ++
 Documentation/driver-api/index.rst |   1 +
 Documentation/firmware_class/README| 128 
 drivers/firmware/dell_rbu.c|   1 +
 drivers/leds/leds-lp55xx-common.c  |   1 +
 include/linux/firmware.h   |   7 +
 .../api/request_firmware-custom-fallback.cocci |  44 +
 tools/testing/selftests/firmware/fw_filesystem.sh  |  25 ++-
 17 files changed, 565 insertions(+), 133 deletions(-)
 create mode 100644 Documentation/driver-api/firmware/built-in-fw.rst
 create mode 100644 Documentation/driver-api/firmware/core.rst
 create mode 100644 Documentation/driver-api/firmware/direct-fs-lookup.rst
 create mode 100644 Documentation/driver-api/firmware/fallback-mechanisms.rst
 create mode 100644 Documentation/driver-api/firmware/firmware_cache.rst
 create mode 100644 Documentation/driver-api/firmware/fw_search_path.rst
 create mode 100644 Documentation/driver-api/firmware/index.rst
 create mode 100644 Documentation/driver-api/firmware/introduction.rst
 create mode 100644 Documentation/driver-api/firmware/lookup-order.rst
 create mode 100644 Documentation/driver-api/firmware/request_firmware.rst
 delete mode 100644 Documentation/firmware_class/README
 create mode 100644 
scripts/coccinelle/api/request_firmware-custom-fallback.cocci

-- 
2.10.1



Re: [PATCH v2 0/6] UBIFS related fscrypt updates

2016-12-12 Thread Theodore Ts'o
On Tue, Dec 06, 2016 at 11:53:52PM +0100, David Gstir wrote:
> This series applies on top of Ted's fscrypt tree[0] addresses the review
> comments from Eric.

This patch series have been added to the fsbranch of the ext4.git
tree, thanks.

- Ted


Re: [PATCH 0/6] USB support for Broadcom NSP SoC

2016-12-12 Thread Florian Fainelli
On 11/09/2016 01:33 AM, Yendapally Reddy Dhananjaya Reddy wrote:
> This patch set contains the usb support for Broadcom NSP SoC.
> The usb phy is connected through mdio interface. The mdio interface
> can be used to access either internal phys or external phys using a
> multiplexer.
> 
> The first patch provides the documentation details for mdio-mux and
> second patch provides the documentation details for usb3 phy. The third
> patch contains the mdio-mux support and fourth patch contains the
> changes to the mdio bus driver.
> 
> The fifth patch provides the phy driver and sixth patch provides the
> enable method for usb.
> 
> This patch series has been tested on NSP bcm958625HR board.
> This patch series is based on v4.9.0-rc1 and is available from github-
> repo: https://github.com/Broadcom/cygnus-linux.git
> branch:nsp-usb-v1

Can you resubmit this patch series with the feedback from Andrew, Rob
and Scott addressed?

Thanks!
-- 
Florian


Re: [PATCH v2 1/4] net: hix5hd2_gmac: add generic compatible string

2016-12-12 Thread Dongpo Li


On 2016/12/12 22:21, Rob Herring wrote:
> On Mon, Dec 12, 2016 at 5:16 AM, Dongpo Li  wrote:
>> Hi Rob,
>>
>> On 2016/12/10 6:35, Rob Herring wrote:
>>> On Mon, Dec 05, 2016 at 09:27:58PM +0800, Dongpo Li wrote:
 The "hix5hd2" is SoC name, add the generic ethernet driver name.
 The "hisi-gemac-v1" is the basic version and "hisi-gemac-v2" adds
 the SG/TXCSUM/TSO/UFO features.

 Signed-off-by: Dongpo Li 
 ---
  .../devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt|  9 +++--
  drivers/net/ethernet/hisilicon/hix5hd2_gmac.c | 15 
 +++
  2 files changed, 18 insertions(+), 6 deletions(-)

 diff --git 
 a/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt 
 b/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
 index 75d398b..75920f0 100644
 --- a/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
 +++ b/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
 @@ -1,7 +1,12 @@
  Hisilicon hix5hd2 gmac controller

  Required properties:
 -- compatible: should be "hisilicon,hix5hd2-gmac".
 +- compatible: should contain one of the following SoC strings:
 +* "hisilicon,hix5hd2-gemac"
 +* "hisilicon,hi3798cv200-gemac"
 +and one of the following version string:
 +* "hisilicon,hisi-gemac-v1"
 +* "hisilicon,hisi-gemac-v2"
>>>
>>> What combinations are valid? I assume both chips don't have both v1 and
>>> v2. 2 SoCs and 2 versions so far, I don't think there is much point to
>>> have the v1 and v2 compatible strings.
>>>
>> The v1 and v2 are generic MAC compatible strings, many HiSilicon SoCs may
>> use the same MAC version. For example,
>> hix5hd2, hi3716cv200 SoCs use the v1 MAC version,
>> hi3798cv200, hi3516a SoCs use the v2 MAC version,
>> and there may be more SoCs added in future.
>> So I think the generic compatible strings are okay here.
>> Should I add the hi3716cv200, hi3516a SoCs compatible here?
> 
> Yes.
> 
>> Do you have any good advice?
>>
  - reg: specifies base physical address(s) and size of the device 
 registers.
The first region is the MAC register base and size.
The second region is external interface control register.
 @@ -20,7 +25,7 @@ Required properties:

  Example:
  gmac0: ethernet@f984 {
 -compatible = "hisilicon,hix5hd2-gmac";
 +compatible = "hisilicon,hix5hd2-gemac", 
 "hisilicon,hisi-gemac-v1";
>>>
>>> You can't just change compatible strings.
>>>
>> Okay, maybe I should name all the compatible string with the suffix "-gmac" 
>> instead of
>> "-gemac". This can keep the compatible strings with the same suffix. Is this 
>> okay?
>> Can I just add the generic compatible string without changing the SoCs 
>> compatible string?
>> Like following:
>> gmac0: ethernet@f984 {
>>  -  compatible = "hisilicon,hix5hd2-gmac";
>>  +  compatible = "hisilicon,hix5hd2-gmac", 
>> "hisilicon,hisi-gmac-v1";
> 
> Yes, this is fine.
> 
Many thanks for your advice.
As the patch series have been applied to net-next branch,
in which way should I commit this compatible fix?
Should I send a new patch with "Fixes: "?


Regards,
Dongpo

.



[GIT PULL] clk: changes for v4.10

2016-12-12 Thread Stephen Boyd
The following changes since commit b7d79eb4615e3eb5947355f7b4354818cba037f7:

  clk: bcm: Fix unmet Kconfig dependencies for CLK_BCM_63XX (2016-11-23 
14:31:11 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git tags/clk-for-linus

for you to fetch changes up to 2aab7a2055a1705c9e30920d95a596226999eb21:

  clk: bcm: Fix 'maybe-uninitialized' warning in 
bcm2835_clock_choose_div_and_prate() (2016-12-12 11:25:40 -0800)


This is a fairly quiet release. We don't have any patches to the core
framework. The only patch that can even be considered "core" adds another
clk_get() variant. The rest of the changes are in drivers for various SoCs, and
we have a few bits for ARM shmobile architecture code (dts and mach) due to the
dependency we're breaking between shmobile architecture code and its clk
driver. Those shmobile bits have also been pulled into arm-soc tree. Here's the
summary:

Core:

 - Support for devm_get_clk_from_child() used with DT bindings that have
   subnodes with the 'clocks' property

New Drivers:

 - Allwinner A64 (sun50i)
 - i.MX imx6ull
 - Socionext's UniPhier SoC CPUs
 - Mediatek MT2701 SoCs
 - Rockchip rk1108 SoCs
 - Qualcomm MSM8994/MSM8992 SoCS
 - Qualcomm RPM Clocks
 - Hisilicon Hi3516CV300 and Hi3798CV200 CRG
 - Oxford Semiconductor OX820 and OX810SE SoCs
 - Renesas RZ/G1M and RZ/GIE SoCs
 - Renesas R-Car RST driver for mode pin states

Updates:

 - Four Allwinner SoCs are migrated to the new style clk driver
 - Rockchip rk3399,rk3066 PLL optimizations
 - i.MX LVDS display glitch fixes and AV PLL precision improvements
 - Qualcomm MSM8996 GPU GDSCs, hw controlled GDSCs, and Alpha PLL support
 - Explicit demodularization of always builtin drivers
 - Freescale Qoriq ls1012a and ls1046a support
 - Exynos 5433 parent typo fix and critical clock tagging
 - Renesas r8a7743/r8a7745 CPG
 - Renesas R-Car M3-W CSI2/VIN/SYS-DMAC/(H)SCIF/I2C/DRIF/gfx support
 - stm32f4* LSI, LSE, RTC, and QSPI clocks
 - pxa27x and pxa25x cpufreq as clks
 - TI omap36xx sprz319 advisory 2.1 workaround
 - Broadcom bcm2835 rate change propogation to PLLH_AUX from VEC


Abhishek Sahu (1):
  clk: qcom: ipq4019: changed i2c freq table

Arnd Bergmann (2):
  clk: pxa mark dummy helper as 'inline'
  clk: pxa: fix pxa2xx_determine_rate return

Arvind Yadav (6):
  clk: nxp: clk-lpc18xx-ccu: Unmap region obtained by of_iomap
  clk: mmp: clk-of-pxa1928: Free memory obtained by kzalloc
  clk:mmp:clk-of-pxa910: Free memory and Unmap region obtained by kzmalloc 
and of_iomap
  clk:mmp:clk-of-mmp2: Free memory and Unmap region obtained by kzalloc and 
of_iomap
  clk: keystone: pll: Unmap region obtained by of_iomap
  clk: st: clk-flexgen: Unmap region obtained by of_iomap

Axel Lin (1):
  clk: qcom: lcc-ipq806x: Fixup overriding val in regmap_read call

Bai Ping (1):
  clk: imx: clk-imx6ul: add clk support for imx6ull

Bastian Köcher (1):
  clk: qcom: Add support for msm8994 global clock controller

Boris Brezillon (5):
  clk: bcm2835: Fix ->fixed_divider of pllh_aux
  clk: bcm2835: Avoid overwriting the div info when disabling a pll_div clk
  clk: bcm: Support rate change propagation on bcm2835 clocks
  clk: bcm: Allow rate change propagation to PLLH_AUX on VEC clock
  clk: bcm: Fix 'maybe-uninitialized' warning in 
bcm2835_clock_choose_div_and_prate()

Chen-Yu Tsai (2):
  clk: sunxi-ng: sun8i-a23: Set CLK_SET_RATE_PARENT for audio module clocks
  clk: sunxi-ng: sun8i-h3: Set CLK_SET_RATE_PARENT for audio module clocks

Christophe JAILLET (1):
  clk: cdce925: Fix limit check

Elaine Zhang (1):
  clk: rockchip: validity should be checked prior to cpu clock rate change

Emil Lundmark (1):
  clk: imx: improve precision of AV PLL to 1 Hz

Fabio Estevam (1):
  clk: imx6: Fix procedure to switch the parent of LDB_DI_CLK

Gabriel Fernandez (3):
  clk: stm32f4: Add LSI & LSE clocks
  clk: stm32f4: Add RTC clock
  clk: stm32f469: Add QSPI clock

Geert Uytterhoeven (30):
  clk: renesas: cpg-mssr: Always use readl()/writel()
  clk: renesas: rcar-gen3-cpg: Always use readl()/writel()
  clk: renesas: cpg-mssr: Fix inverted debug check
  clk: renesas: cpg-mssr: Fix inverted debug check
  clk: renesas: cpg-mssr: Remove bogus commas from error messages
  reset: Add renesas,rst DT bindings
  soc: renesas: Add R-Car RST driver
  ARM: dts: r8a7778: Add device node for RESET/WDT module
  ARM: dts: r8a7779: Add device node for RESET/WDT module
  ARM: dts: r8a7790: Add device node for RST module
  ARM: dts: r8a7791: Add device node for RST module
  ARM: dts: r8a7792: Add device node for RST module
  ARM: dts: r8a7793: Add device node for RST module
  ARM: dts: r8a7794: Add device node for RST module
  arm64: 

[PATCH v3] llist: Clarify comments about when locking is needed

2016-12-12 Thread Joel Fernandes
llist.h comments are confusing about when locking is needed versus when it
isn't. Clarify these comments by being more descriptive about why locking is
needed for llist_del_first.

Cc: Ingo Molnar 
Cc: Will Deacon 
Cc: Paul McKenney 
Acked-by: Huang Ying 
Acked-by: Mathieu Desnoyers 
Signed-off-by: Joel Fernandes 
---
Changes since before:
Minor changes to comment and commit message based on Mathieu's suggestions
(https://lkml.org/lkml/2016/12/10/39)

 include/linux/llist.h | 37 +
 1 file changed, 21 insertions(+), 16 deletions(-)

diff --git a/include/linux/llist.h b/include/linux/llist.h
index fd4ca0b..31822bb 100644
--- a/include/linux/llist.h
+++ b/include/linux/llist.h
@@ -3,28 +3,33 @@
 /*
  * Lock-less NULL terminated single linked list
  *
- * If there are multiple producers and multiple consumers, llist_add
- * can be used in producers and llist_del_all can be used in
- * consumers.  They can work simultaneously without lock.  But
- * llist_del_first can not be used here.  Because llist_del_first
- * depends on list->first->next does not changed if list->first is not
- * changed during its operation, but llist_del_first, llist_add,
- * llist_add (or llist_del_all, llist_add, llist_add) sequence in
- * another consumer may violate that.
- *
- * If there are multiple producers and one consumer, llist_add can be
- * used in producers and llist_del_all or llist_del_first can be used
- * in the consumer.
- *
- * This can be summarized as follow:
+ * Cases where locking is not needed:
+ * If there are multiple producers and multiple consumers, llist_add can be
+ * used in producers and llist_del_all can be used in consumers simultaneously
+ * without locking. Also a single consumer can use llist_del_first while
+ * multiple producers simultaneously use llist_add, without any locking.
+ *
+ * Cases where locking is needed:
+ * If we have multiple consumers with llist_del_first used in one consumer, and
+ * llist_del_first or llist_del_all used in other consumers, then a lock is
+ * needed.  This is because llist_del_first depends on list->first->next not
+ * changing, but without lock protection, there's no way to be sure about that
+ * if a preemption happens in the middle of the delete operation and on being
+ * preempted back, the list->first is the same as before causing the cmpxchg in
+ * llist_del_first to succeed. For example, while a llist_del_first operation
+ * is in progress in one consumer, then a llist_del_first, llist_add,
+ * llist_add (or llist_del_all, llist_add, llist_add) sequence in another
+ * consumer may cause violations.
+ *
+ * This can be summarized as follows:
  *
  *   |   add| del_first |  del_all
  * add   |- | - | -
  * del_first |  | L | L
  * del_all   |  |   | -
  *
- * Where "-" stands for no lock is needed, while "L" stands for lock
- * is needed.
+ * Where, a particular row's operation can happen concurrently with a column's
+ * operation, with "-" being no lock needed, while "L" being lock is needed.
  *
  * The list entries deleted via llist_del_all can be traversed with
  * traversing function such as llist_for_each etc.  But the list
-- 
2.8.0.rc3.226.g39d4020



[PATCH RFC] [media] s5k6aa: set usleep_range greater 0

2016-12-12 Thread Nicholas Mc Guire
As this is not in atomic context and it does not seem like a critical 
timing setting a range of 1ms allows the timer subsystem to optimize 
the hrtimer here.

Fixes: commit bfa8dd3a0524 ("[media] v4l: Add v4l2 subdev driver for S5K6AAFX 
sensor")
Signed-off-by: Nicholas Mc Guire <hof...@osadl.org>
---

problem was located by coccinelle spatch

The problem is that usleep_range is calculating the delay by
 exp = ktime_add_us(ktime_get(), min)
 delta = (u64)(max - min) * NSEC_PER_USEC
so delta is set to 0
and then calls
  schedule_hrtimeout_range(exp, 0,...)
effectively this means that the clock subsystem has no room to
optimize which makes little sense as this is not atomic context
anyway so there is not guaratee of precision here.

As this is not a critical delay it is set to a range of 4 to 5
milliseconds - this change needs a review by someone that knows
the details of the device though and preferably would increase
that range.

Patch was only compile tested with: x86_64_defconfig + MEDIA_SUPPORT=m
MEDIA_CAMERA_SUPPORT=y (implies VIDEO_V4L2=m)
MEDIA_DIGITAL_TV_SUPPORT=y, CONFIG_MEDIA_CONTROLLER=y,
CONFIG_VIDEO_V4L2_SUBDEV_API=y

Patch is against 4.9.0 (localversion-next is next-20161212)

 drivers/media/i2c/s5k6aa.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/s5k6aa.c b/drivers/media/i2c/s5k6aa.c
index faee113..9fd254a 100644
--- a/drivers/media/i2c/s5k6aa.c
+++ b/drivers/media/i2c/s5k6aa.c
@@ -838,7 +838,7 @@ static int __s5k6aa_power_on(struct s5k6aa *s5k6aa)
 
if (s5k6aa->s_power)
ret = s5k6aa->s_power(1);
-   usleep_range(4000, 4000);
+   usleep_range(4000, 5000);
 
if (s5k6aa_gpio_deassert(s5k6aa, RST))
msleep(20);
-- 
2.1.4



Re: [RFC][PATCHv5 5/7] printk: report lost messages in printk safe/nmi contexts

2016-12-12 Thread Sergey Senozhatsky
On (12/12/16 16:58), Petr Mladek wrote:
> On Thu 2016-12-01 22:55:44, Sergey Senozhatsky wrote:
[..]
> But not really because we report lost messages from both buffers
> and from all CPUs here.
[..]
> The perfect solution would be to remember the number of lost messages
> in struct printk_safe_seq_buf. Then we might bump the value directly
> in printk_safe_log_store() instead of returning the ugly -ENOSPC.

ok, I can take a look. this won't grow the per-CPU buffers bigger,
but will shrink the actual message buffer size by sizeof(atomic),
not that dramatic.

* unrelated, can be done later (if ever) *

speaking of tha actual message buffer size, we, may be, can move
`struct irq_work' out of printk_safe_seq_buf. there is already
a printk-related per-CPU irq_work in place - wake_up_klogd_work.
so we may be can use it, instead of defining a bunch of new irq_works.
this will increase the printk-safe/nmi per-CPU message buffer size
by sizeof(irq_work).

> Also we could use an universal message (no "NMI" or "printk-safe")
> because it could be printed right after flushing the messages
> that fit the buffer.

this "context" part probably can be dropped. both printk-safe and
printk-nmi per-CPU buffer sizes are controlled by a single .config
option anyway; user can't increase the printk-safe buffer size
without increasing the printk-nmi buffer size (in case if printk-safe
buffer is too small).

> This solution is good enough and still better than the previous one, so
> 
> Reviewed-by: Petr Mladek 

thanks.

-ss


Re: [LKP] [lkp-developer] [sched/fair] 4e5160766f: +149% ftq.noise.50% regression

2016-12-12 Thread Huang, Ying
Hi, Vincent,

Vincent Guittot  writes:

> Hi Ying,
>
> On 12 December 2016 at 06:43, kernel test robot
>  wrote:
>> Greeting,
>>
>> FYI, we noticed a 149% regression of ftq.noise.50% due to commit:
>>
>>
>> commit: 4e5160766fcc9f41bbd38bac11f92dce993644aa ("sched/fair: Propagate 
>> asynchrous detach")
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>>
>> in testcase: ftq
>> on test machine: 8 threads Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz with 8G 
>> memory
>> with following parameters:
>>
>> nr_task: 100%
>> samples: 6000ss
>> test: cache
>> freq: 20
>> cpufreq_governor: powersave
>
> Why using powersave ? Are you testing  every governors ?

We will test performance and powersave governor for FTQ.

>>
>> test-description: The FTQ benchmarks measure hardware and software 
>> interference or 'noise' on a node from the applications perspective.
>> test-url: https://github.com/rminnich/ftq
>
> It's a bit difficult to understand exactly what is measured and what
> is ftq.noise.50% because this result is not part of the bench which
> seems to only record a log of data in a file and ftq.noise.50% seems
> to be lkp specific

Yes. FTQ itself has no noise statistics builtin, although it is an OS
noise benchmark.  ftq.noise.50% is calculated as below:

There is a score for every sample of ftq.  The lower the score, the
higher the noises.  ftq.noise.50% is the number (per 100 samples) of
samples whose score is less than 50% of the mean score.

Best Regards,
Huang, Ying

> I have tried to reproduce the lkp test on a debian jessie then a
> ubuntu server 16.10 but lkp doesn't seems to install cleanly as there
> are some errors:
>
> sudo bin/lkp run job.yaml
> IPMI BMC is not supported on this machine, skip bmc-watchdog setup!
> 2016-12-12 13:58:39 ./ftq_cache -f 20 -n 6000 -t 8 -a 524288
> Start 5088418680237 end 5438443372098 elapsed 350024691861
> cyclestart 14236344834332 cycleend 15214154208877 elapsed 977809374545
> Avg Cycles(ticks) per ns. is 2.793544; nspercycle is 0.357968
> Pre-computed ticks per ns: 2.793541
> Sample frequency is 20.00
> ticks per ns 2.79354
> chown: utilisateur incorrect: «lkp.lkp»
> chown: utilisateur incorrect: «lkp.lkp»
> wait for background monitors: 9405 9407 oom-killer nfs-hang
> curl: (6) Could not resolve host: ftq.time
>
>
>>
>> In addition to that, the commit also has significant impact on the following 
>> tests:
>>
>> +--++
>> | testcase: change | unixbench: unixbench.score 2.7% improvement 
>>|
>> | test machine | 4 threads Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz with 
>> 4G memory   |
>> | test parameters  | cpufreq_governor=performance
>>|
>> |  | nr_task=100%
>>|
>> |  | runtime=300s
>>|
>> |  | test=execl  
>>|
>> +--++
>>
>>
>> Details are as below:
>> -->
>>
>>
>> To reproduce:
>>
>> git clone 
>> git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
>> cd lkp-tests
>> bin/lkp install job.yaml  # job file is attached in this email
>> bin/lkp run job.yaml
>>
>> testcase/path_params/tbox_group/run: 
>> ftq/100%-6000ss-cache-20-powersave/lkp-hsw-d01
>>
>> 09a43ace1f986b00  4e5160766fcc9f41bbd38bac11
>>   --
>>  %stddev  change %stddev
>>  \  |\
>>305 ± 30%   260%   1100 ± 14%  ftq.noise.75%
>>   1386 ± 19%   149%   3457 ±  7%  ftq.noise.50%
>>   2148 ± 11%98%   4257 ±  4%  ftq.noise.25%
>>3963589 3898578
>> ftq.time.involuntary_context_switches
>>
>>
>>
>>ftq.noise.50_
>>
>>   4000 ++O--+
>>|   O  O |
>>   3500 ++ O OOO O O O
>>| O  O  O   O  O O  O O OO OO   O O  |
>>OO O  O O|
>>   3000 ++   O   |
>>| O  |
>>   2500 ++  

[GIT PULL] ACPI updates for v4.10-rc1 (fixed)

2016-12-12 Thread Rafael J. Wysocki
Hi Linus,

The tag name was incorrect in the one I sent previously, sorry about that.

Please pull from the tag

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 acpi-4.10-rc1

with top-most commit 80f1b3dea9d4262817b5510547b1313681669f66

 Merge branch 'device-properties'

on top of commit 69973b830859bc6529a7a0468ba0d80ee5117826

 Linux 4.9

to receive ACPI updates for v4.10-rc1.

The ACPICA code in the kernel gets updated as usual (included is
upstream revision 20160930 and a few commits from the next one,
with the rest waiting for an issue discovered in linux-next to
be addressed) which brings in a couple of fixes and cleanups.

On top of that initial support for APEI on ARM64 is added, two new
pieces of documentation are introduced, the properties-parsing code
is updated to follow changes in the (external) documentation it is
based on and there are a few updates of SoC drivers, some new
blacklist entries, plus some assorted fixes and cleanups.

Specifics:

 - ACPICA update including upstream revision 20160930 and several
   commits beyond it (Bob Moore, Lv Zheng).

 - Initial support for ACPI APEI on ARM64 (Tomasz Nowicki).

 - New document describing the handling of _OSI and _REV in Linux
   (Len Brown).

 - New document describing the usage rules for _DSD properties
   (Rafael Wysocki).

 - Update of the ACPI properties-parsing code to reflect recent
   changes in the (external) documentation it is based on (Rafael
   Wysocki).

 - Updates of the ACPI LPSS and ACPI APD SoC drivers for additional
   hardware support (Andy Shevchenko, Nehal Shah).

 - New blacklist entries for _REV and video handling (Alex Hung,
   Hans de Goede, Michael Pobega).

 - ACPI battery driver fix to fall back to _BIF if _BIX fails (Dave
   Lambley).

 - NMI notifications handling fix for APEI (Prarit Bhargava).

 - Error code path fix for the ACPI CPPC library (Dan Carpenter).

 - Assorted cleanups (Andy Shevchenko, Longpeng Mike).

Thanks!

---

Alex Hung (1):
  ACPI / blacklist: add _REV quirks for Dell Precision 5520 and 3520

Andy Shevchenko (3):
  ACPI / LPSS: enable hard LLP for DMA
  ACPI / osl: Propagate actual error code for kstrtoul()
  ACPI / osl: Refactor acpi_os_get_root_pointer() to drop 'else':s

Bob Moore (6):
  ACPICA: Update an info message during table load phase
  ACPICA: Increase loop limit for AE_AML_INFINITE_LOOP exception
  ACPICA: Disassembler: Fix for Divide() support, new support for test suite
  ACPICA: Move acpi_gbl_max_loop_iterations to the public globals file
  ACPICA: Update version to 20160930
  ACPICA: Utilities: Add new decode function for parser values

Dan Carpenter (1):
  ACPI / CPPC: set an error code on probe error path

Dave Lambley (1):
  ACPI / battery: If _BIX fails, retry with _BIF

Hans de Goede (3):
  ACPI / video: Move ACPI_VIDEO_NOTIFY_* defines to acpi/video.h
  ACPI / video: Add force_native quirk for Dell XPS 17 L702X
  ACPI / video: Add force_native quirk for HP Pavilion dv6

Len Brown (1):
  ACPI: Document _OSI and _REV for Linux BIOS writers

Longpeng Mike (1):
  ACPI / tebles: remove redundant declare of acpi_table_parse_entries()

Lv Zheng (8):
  ACPICA: MacOSX: Fix anonymous semaphore implementation
  ACPICA: MacOSX: Fix wrong sem_destroy definition
  ACPICA: Namespace: Add acpi_ns_handle_to_name()
  ACPICA: Back port of "ACPICA: Dispatcher: Tune interpreter lock
around AcpiEvInitializeRegion()"
  ACPICA: Events: Fix acpi_ev_initialize_region() return value
  ACPICA: Tables: Cleanup acpi_tb_install_and_load_table()
  ACPICA: Tables: Add acpi_tb_unload_table()
  ACPICA: Tables: Add an error message complaining driver bugs

Michael Pobega (1):
  ACPI / blacklist: Make Dell Latitude 3350 ethernet work

Nehal Shah (1):
  ACPI / APD: Add clock frequency for future AMD I2C controller

Prarit Bhargava (1):
  ACPI / APEI: Fix NMI notification handling

Rafael J. Wysocki (2):
  ACPI / property: Hierarchical properties support update
  ACPI / property: Document usage rules for _DSD properties

Tomasz Nowicki (1):
  ACPI / APEI / ARM64: APEI initial support for ARM64

---

 Documentation/acpi/DSD-properties-rules.txt|  97 +++
 Documentation/acpi/enumeration.txt |   9 +
 Documentation/acpi/osi.txt | 187 +
 arch/arm64/Kconfig |   1 +
 arch/arm64/include/asm/acpi.h  |  23 ++-
 arch/x86/kernel/acpi/apei.c|   3 -
 drivers/acpi/acpi_apd.c|   7 +-
 drivers/acpi/acpi_lpss.c   |   8 +-
 drivers/acpi/acpi_video.c  |  11 --
 drivers/acpi/acpica/acevents.h |   4 +-
 drivers/acpi/acpica/acglobal.h |   5 +-
 drivers/acpi/acpica/aclocal.h  |  

Re: [PATCH v5] cgroup: Add new capability to allow a process to migrate other tasks between cgroups

2016-12-12 Thread John Stultz
On Mon, Dec 12, 2016 at 5:39 PM, John Stultz  wrote:
> This patch adds CAP_GROUP_MIGRATE and logic to allows a process
> to migrate other tasks between cgroups.
>
> In Android (where this feature originated), the ActivityManager
> tracks various application states (TOP_APP, FOREGROUND,
> BACKGROUND, SYSTEM, etc), and then as applications change
> states, the SchedPolicy logic will migrate the application tasks
> between different cgroups used to control the different
> application states (for example, there is a background cpuset
> cgroup which can limit background tasks to stay on one low-power
> cpu, and the bg_non_interactive cpuctrl cgroup can then further
> limit those background tasks to a small percentage of that one
> cpu's cpu time).
>
> However, for security reasons, Android doesn't want to make the
> system_server (the process that runs the ActivityManager and
> SchedPolicy logic), run as root. So in the Android common.git
> kernel, they have some logic to allow cgroups to loosen their
> permissions so CAP_SYS_NICE tasks can migrate other tasks between
> cgroups.
>
> I feel the approach taken there overloads CAP_SYS_NICE a bit much
> for non-android environments. Efforts to re-use CAP_SYS_RESOURCE
> for this purpose (which Android has since adopted) was also
> stymied by concerns about risks from future cgroups that could be
> considered "dangerous" by how they might change system semantics.
>
> So to avoid overlapping usage, this patch adds a brand new
> process capability flag (CAP_CGROUP_MIGRATE), and uses it when
> checking if a task can migrate other tasks between cgroups.
>
> I've tested this with AOSP master (though its a bit hacked in as
> I still need to properly get the selinux bits aware of the new
> capability bit) with selinux set to permissive and it seems to be
> working well.
>
> Thoughts and feedback would be appreciated!
>
> Cc: Tejun Heo 
> Cc: Li Zefan 
> Cc: Jonathan Corbet 
> Cc: cgro...@vger.kernel.org
> Cc: Android Kernel Team 
> Cc: Rom Lemarchand 
> Cc: Colin Cross 
> Cc: Dmitry Shmidt 
> Cc: Todd Kjos 
> Cc: Christian Poetzsch 
> Cc: Amit Pundir 
> Cc: Dmitry Torokhov 
> Cc: Kees Cook 
> Cc: Serge E. Hallyn 
> Cc: Andy Lutomirski 
> Cc: linux-...@vger.kernel.org
> Acked-by: Serge Hallyn 

After sending this I just realized that this is changed enough I
should probably remove Serge's Acked-by here. Apologies.

But otherwise feedback on this would be appreciated!

thanks
-john


Re: [PATCH v1 12/12] scsi: ufs: Improve fatal error logs

2016-12-12 Thread Subhash Jadavani

On 2016-12-12 17:19, Joe Perches wrote:

On Mon, 2016-12-12 at 16:56 -0800, Subhash Jadavani wrote:

Errors such as UIC error, illegal OCS values, and others may require
more information for debugging. Such information could be hibern8 
events,

events sequences, recoverable errors, error history, and more.

[]

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c

[]
@@ -346,6 +346,37 @@ static inline void 
ufshcd_cond_add_cmd_trace(struct ufs_hba *hba,

[]

+static void ufshcd_print_uic_err_hist(struct ufs_hba *hba,
+   struct ufs_uic_err_reg_hist *err_hist, char *err_name)
+{
+   int i;
+
+   for (i = 0; i < UIC_ERR_REG_HIST_LENGTH; i++) {
+   int p = (i + err_hist->pos - 1) % UIC_ERR_REG_HIST_LENGTH;
+
+   if (err_hist->reg[p] == 0)
+   continue;
+   dev_err(hba->dev, "%s[%d] = 0x%x at %lld us", err_name, i,
+   err_hist->reg[p], ktime_to_us(err_hist->tstamp[p]));


Please consistently use a terminating \n


Sure, will do that. Thanks.




+   }
+}
+
 static void ufshcd_print_host_regs(struct ufs_hba *hba)
 {
/*
@@ -362,6 +393,21 @@ static void ufshcd_print_host_regs(struct ufs_hba 
*hba)

dev_err(hba->dev,
"hba->outstanding_reqs = 0x%x, hba->outstanding_tasks = 0x%x",
(u32)hba->outstanding_reqs, (u32)hba->outstanding_tasks);
+   dev_err(hba->dev,
+   "last_hibern8_exit_tstamp at %lld us, hibern8_exit_cnt = %d",


etc...

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" 
in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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


[PATCH v5] cgroup: Add new capability to allow a process to migrate other tasks between cgroups

2016-12-12 Thread John Stultz
This patch adds CAP_GROUP_MIGRATE and logic to allows a process
to migrate other tasks between cgroups.

In Android (where this feature originated), the ActivityManager
tracks various application states (TOP_APP, FOREGROUND,
BACKGROUND, SYSTEM, etc), and then as applications change
states, the SchedPolicy logic will migrate the application tasks
between different cgroups used to control the different
application states (for example, there is a background cpuset
cgroup which can limit background tasks to stay on one low-power
cpu, and the bg_non_interactive cpuctrl cgroup can then further
limit those background tasks to a small percentage of that one
cpu's cpu time).

However, for security reasons, Android doesn't want to make the
system_server (the process that runs the ActivityManager and
SchedPolicy logic), run as root. So in the Android common.git
kernel, they have some logic to allow cgroups to loosen their
permissions so CAP_SYS_NICE tasks can migrate other tasks between
cgroups.

I feel the approach taken there overloads CAP_SYS_NICE a bit much
for non-android environments. Efforts to re-use CAP_SYS_RESOURCE
for this purpose (which Android has since adopted) was also
stymied by concerns about risks from future cgroups that could be
considered "dangerous" by how they might change system semantics.

So to avoid overlapping usage, this patch adds a brand new
process capability flag (CAP_CGROUP_MIGRATE), and uses it when
checking if a task can migrate other tasks between cgroups.

I've tested this with AOSP master (though its a bit hacked in as
I still need to properly get the selinux bits aware of the new
capability bit) with selinux set to permissive and it seems to be
working well.

Thoughts and feedback would be appreciated!

Cc: Tejun Heo 
Cc: Li Zefan 
Cc: Jonathan Corbet 
Cc: cgro...@vger.kernel.org
Cc: Android Kernel Team 
Cc: Rom Lemarchand 
Cc: Colin Cross 
Cc: Dmitry Shmidt 
Cc: Todd Kjos 
Cc: Christian Poetzsch 
Cc: Amit Pundir 
Cc: Dmitry Torokhov 
Cc: Kees Cook 
Cc: Serge E. Hallyn 
Cc: Andy Lutomirski 
Cc: linux-...@vger.kernel.org
Acked-by: Serge Hallyn 
Signed-off-by: John Stultz 
---
v2: Renamed to just CAP_CGROUP_MIGRATE as reccomended by Tejun
v3: Switched to just using CAP_SYS_RESOURCE as suggested by Michael
v4: Send out properly folded down version of the patch. :P
v5: Switch back to CAP_CGROUP_MIGRATE due to concerns from Andy
---
 include/uapi/linux/capability.h | 5 -
 kernel/cgroup.c | 3 ++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
index 49bc062..32d3829 100644
--- a/include/uapi/linux/capability.h
+++ b/include/uapi/linux/capability.h
@@ -349,8 +349,11 @@ struct vfs_cap_data {
 
 #define CAP_AUDIT_READ 37
 
+/* Allow migration of other tasks between cgroups */
 
-#define CAP_LAST_CAP CAP_AUDIT_READ
+#define CAP_CGROUP_MIGRATE 38
+
+#define CAP_LAST_CAP CAP_CGROUP_MIGRATE
 
 #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
 
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 2ee9ec3..784f115 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -2856,7 +2856,8 @@ static int cgroup_procs_write_permission(struct 
task_struct *task,
 */
if (!uid_eq(cred->euid, GLOBAL_ROOT_UID) &&
!uid_eq(cred->euid, tcred->uid) &&
-   !uid_eq(cred->euid, tcred->suid))
+   !uid_eq(cred->euid, tcred->suid) &&
+   !ns_capable(tcred->user_ns, CAP_CGROUP_MIGRATE))
ret = -EACCES;
 
if (!ret && cgroup_on_dfl(dst_cgrp)) {
-- 
2.7.4



Re: [LKP] [lkp-developer] [mm] 4db18597f8: invoked_oom-killer:gfp_mask=0x

2016-12-12 Thread Huang, Ying
Michal Hocko  writes:

> Hi,
> the subject suggests there was an OOM killer invocation but there is
> nothing like that in the attached log. Is the full log somewhere
> availble?

Sorry, there is not OOM killer invocation, just page allocation stall.
I misread some text in the original log.

Best Regards,
Huang, Ying


[PATCH v2 2/2] crypto: mediatek - add DT bindings documentation

2016-12-12 Thread Ryder Lee
Add DT bindings documentation for the crypto driver

Signed-off-by: Ryder Lee 
---
 .../devicetree/bindings/crypto/mediatek-crypto.txt | 32 ++
 1 file changed, 32 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/crypto/mediatek-crypto.txt

diff --git a/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt 
b/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
new file mode 100644
index 000..47a786e
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
@@ -0,0 +1,32 @@
+MediaTek cryptographic accelerators
+
+Required properties:
+- compatible: Should be "mediatek,eip97-crypto"
+- reg: Address and length of the register set for the device
+- interrupts: Should contain the five crypto engines interrupts in numeric
+   order. These are global system and four descriptor rings.
+- clocks: the clock used by the core
+- clock-names: the names of the clock listed in the clocks property. These are
+   "ethif", "cryp"
+- power-domains: Must contain a reference to the PM domain.
+
+
+Optional properties:
+- interrupt-parent: Should be the phandle for the interrupt controller
+  that services interrupts for this device
+
+
+Example:
+   crypto: crypto@1b24 {
+   compatible = "mediatek,eip97-crypto";
+   reg = <0 0x1b24 0 0x2>;
+   interrupts = ,
+,
+,
+,
+;
+   clocks = < CLK_TOP_ETHIF_SEL>,
+< CLK_ETHSYS_CRYPTO>;
+   clock-names = "ethif","cryp";
+   power-domains = < MT2701_POWER_DOMAIN_ETH>;
+   };
-- 
1.9.1



[PATCH v2 1/2] Add crypto driver support for some MediaTek chips

2016-12-12 Thread Ryder Lee
This adds support for the MediaTek hardware accelerator on
mt7623/mt2701/mt8521p SoC.

This driver currently implement:
- SHA1 and SHA2 family(HMAC) hash algorithms.
- AES block cipher in CBC/ECB mode with 128/196/256 bits keys.

Signed-off-by: Ryder Lee 
---
 drivers/crypto/Kconfig |   17 +
 drivers/crypto/Makefile|1 +
 drivers/crypto/mediatek/Makefile   |2 +
 drivers/crypto/mediatek/mtk-aes.c  |  766 +
 drivers/crypto/mediatek/mtk-platform.c |  604 ++
 drivers/crypto/mediatek/mtk-platform.h |  238 ++
 drivers/crypto/mediatek/mtk-regs.h |  194 +
 drivers/crypto/mediatek/mtk-sha.c  | 1437 
 8 files changed, 3259 insertions(+)
 create mode 100644 drivers/crypto/mediatek/Makefile
 create mode 100644 drivers/crypto/mediatek/mtk-aes.c
 create mode 100644 drivers/crypto/mediatek/mtk-platform.c
 create mode 100644 drivers/crypto/mediatek/mtk-platform.h
 create mode 100644 drivers/crypto/mediatek/mtk-regs.h
 create mode 100644 drivers/crypto/mediatek/mtk-sha.c

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 4d2b81f..937039d 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -553,6 +553,23 @@ config CRYPTO_DEV_ROCKCHIP
  This driver interfaces with the hardware crypto accelerator.
  Supporting cbc/ecb chainmode, and aes/des/des3_ede cipher mode.
 
+config CRYPTO_DEV_MEDIATEK
+   tristate "MediaTek's EIP97 Cryptographic Engine driver"
+   depends on ARM && (ARCH_MEDIATEK || COMPILE_TEST)
+   select NEON
+   select KERNEL_MODE_NEON
+   select ARM_CRYPTO
+   select CRYPTO_AES
+   select CRYPTO_BLKCIPHER
+   select CRYPTO_SHA1_ARM_NEON
+   select CRYPTO_SHA256_ARM
+   select CRYPTO_SHA512_ARM
+   select CRYPTO_HMAC
+   help
+ This driver allows you to utilize the hardware crypto accelerator
+ EIP97 which can be found on the MT7623 MT2701, MT8521p, etc 
+ Select this if you want to use it for AES/SHA1/SHA2 algorithms.
+
 source "drivers/crypto/chelsio/Kconfig"
 
 endif # CRYPTO_HW
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index ad7250f..272b51a 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_CRYPTO_DEV_IMGTEC_HASH) += img-hash.o
 obj-$(CONFIG_CRYPTO_DEV_IXP4XX) += ixp4xx_crypto.o
 obj-$(CONFIG_CRYPTO_DEV_MV_CESA) += mv_cesa.o
 obj-$(CONFIG_CRYPTO_DEV_MARVELL_CESA) += marvell/
+obj-$(CONFIG_CRYPTO_DEV_MEDIATEK) += mediatek/
 obj-$(CONFIG_CRYPTO_DEV_MXS_DCP) += mxs-dcp.o
 obj-$(CONFIG_CRYPTO_DEV_NIAGARA2) += n2_crypto.o
 n2_crypto-y := n2_core.o n2_asm.o
diff --git a/drivers/crypto/mediatek/Makefile b/drivers/crypto/mediatek/Makefile
new file mode 100644
index 000..187be79
--- /dev/null
+++ b/drivers/crypto/mediatek/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_CRYPTO_DEV_MEDIATEK) += mtk-crypto.o
+mtk-crypto-objs:= mtk-platform.o mtk-aes.o mtk-sha.o
diff --git a/drivers/crypto/mediatek/mtk-aes.c 
b/drivers/crypto/mediatek/mtk-aes.c
new file mode 100644
index 000..aa915c6
--- /dev/null
+++ b/drivers/crypto/mediatek/mtk-aes.c
@@ -0,0 +1,766 @@
+/*
+ * Cryptographic API.
+ *
+ * Driver for EIP97 AES acceleration.
+ *
+ * Copyright (c) 2016 Ryder Lee 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Some ideas are from atmel-aes.c drivers.
+ */
+
+#include 
+#include "mtk-platform.h"
+
+#define AES_QUEUE_SIZE 512
+#define AES_BUF_ORDER  2
+#define AES_BUF_SIZE   ((PAGE_SIZE << AES_BUF_ORDER) \
+   & ~(AES_BLOCK_SIZE - 1))
+
+/* AES command token */
+#define AES_CT_SIZE_ECB2
+#define AES_CT_SIZE_CBC3
+#define AES_CT_CTRL_HDRcpu_to_le32(0x0022)
+#define AES_COMMAND0   cpu_to_le32(0x0500)
+#define AES_COMMAND1   cpu_to_le32(0x2d06)
+#define AES_COMMAND2   cpu_to_le32(0xe4a63806)
+
+/* AES transform information */
+#define AES_TFM_ECBcpu_to_le32(0x0 << 0)
+#define AES_TFM_CBCcpu_to_le32(0x1 << 0)
+#define AES_TFM_DECRYPTcpu_to_le32(0x5 << 0)
+#define AES_TFM_ENCRYPTcpu_to_le32(0x4 << 0)
+#define AES_TFM_SIZE(x)cpu_to_le32((x) << 8)
+#define AES_TFM_128BITScpu_to_le32(0xb << 16)
+#define AES_TFM_192BITScpu_to_le32(0xd << 16)
+#define AES_TFM_256BITScpu_to_le32(0xf << 16)
+#define AES_TFM_FULL_IVcpu_to_le32(0xf << 5)
+
+/* AES flags */
+#define AES_FLAGS_MODE_MSK 0x7
+#define AES_FLAGS_ECB  BIT(0)
+#define AES_FLAGS_CBC  BIT(1)
+#define AES_FLAGS_ENCRYPT  BIT(2)
+#define AES_FLAGS_BUSY BIT(3)
+
+/**
+ * mtk_aes_ct 

[PATCH v2 0/2] Add MediaTek crypto accelerator driver

2016-12-12 Thread Ryder Lee
Hello,

This adds support for the MediaTek hardware accelerator on
some SoCs.

This driver currently implement: 
- SHA1 and SHA2 family(HMAC) hash algorithms.
- AES block cipher in CBC/ECB mode with 128/196/256 bits keys.

Changes since v2:
- use byteorder conversion macros and type identifiers for descriptors
- revise register definition macros to make it more clear
- revise DT compatiable string

Changes since v1:
- remove EXPORT_SYMBOL
- remove unused PRNG setting
- sort headers in alphabetical order
- add a definition for IRQ unmber
- replace ambiguous definition
- add more annotation and function comment
- add COMPILE_TEST in Kconfig

Ryder Lee (2):
  Add crypto driver support for some MediaTek chips
  crypto: mediatek - add DT bindings documentation

 .../devicetree/bindings/crypto/mediatek-crypto.txt |   32 +
 drivers/crypto/Kconfig |   17 +
 drivers/crypto/Makefile|1 +
 drivers/crypto/mediatek/Makefile   |2 +
 drivers/crypto/mediatek/mtk-aes.c  |  766 +++
 drivers/crypto/mediatek/mtk-platform.c |  604 
 drivers/crypto/mediatek/mtk-platform.h |  238 
 drivers/crypto/mediatek/mtk-regs.h |  194 +++
 drivers/crypto/mediatek/mtk-sha.c  | 1437 
 9 files changed, 3291 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
 create mode 100644 drivers/crypto/mediatek/Makefile
 create mode 100644 drivers/crypto/mediatek/mtk-aes.c
 create mode 100644 drivers/crypto/mediatek/mtk-platform.c
 create mode 100644 drivers/crypto/mediatek/mtk-platform.h
 create mode 100644 drivers/crypto/mediatek/mtk-regs.h
 create mode 100644 drivers/crypto/mediatek/mtk-sha.c

-- 
1.9.1



Re: [PATCH v2 1/2] tracing/kprobes: add a helper method to return number of probe hits

2016-12-12 Thread Masami Hiramatsu
Hello Marcin,

On Fri, 9 Dec 2016 15:19:37 +0100
Marcin Nowakowski  wrote:

> The number of probe hits is stored in a percpu variable and therefore
> can't be read directly. Add a helper method trace_kprobe_nhit() that
> performs the required calculation.
> 
> It will be used in a follow-up commit that changes kprobe selftests to
> verify the number of probe hits.

Ah, that's nicer & neet :)

Acked-by: Masami Hiramatsu 

Thanks!

> 
> Signed-off-by: Marcin Nowakowski 
> ---
>  kernel/trace/trace_kprobe.c | 19 +--
>  1 file changed, 13 insertions(+), 6 deletions(-)
> 
>  v2: improved commit message as suggested by Steven Rostedt
> 
> diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
> index eb6c9f1..a2af1bc 100644
> --- a/kernel/trace/trace_kprobe.c
> +++ b/kernel/trace/trace_kprobe.c
> @@ -73,6 +73,17 @@ static nokprobe_inline bool 
> trace_kprobe_is_on_module(struct trace_kprobe *tk)
>   return !!strchr(trace_kprobe_symbol(tk), ':');
>  }
>  
> +static nokprobe_inline unsigned long trace_kprobe_nhit(struct trace_kprobe 
> *tk)
> +{
> + unsigned long nhit = 0;
> + int cpu;
> +
> + for_each_possible_cpu(cpu)
> + nhit += *per_cpu_ptr(tk->nhit, cpu);
> +
> + return nhit;
> +}
> +
>  static int register_kprobe_event(struct trace_kprobe *tk);
>  static int unregister_kprobe_event(struct trace_kprobe *tk);
>  
> @@ -882,14 +893,10 @@ static const struct file_operations kprobe_events_ops = 
> {
>  static int probes_profile_seq_show(struct seq_file *m, void *v)
>  {
>   struct trace_kprobe *tk = v;
> - unsigned long nhit = 0;
> - int cpu;
> -
> - for_each_possible_cpu(cpu)
> - nhit += *per_cpu_ptr(tk->nhit, cpu);
>  
>   seq_printf(m, "  %-44s %15lu %15lu\n",
> -trace_event_name(>tp.call), nhit,
> +trace_event_name(>tp.call),
> +trace_kprobe_nhit(tk),
>  tk->rp.kp.nmissed);
>  
>   return 0;
> -- 
> 2.7.4
> 


-- 
Masami Hiramatsu 


Re: [PATCH v2 2/2] kprobes/trace: Fix kprobe selftest for newer gcc

2016-12-12 Thread Masami Hiramatsu
On Fri, 9 Dec 2016 15:19:38 +0100
Marcin Nowakowski  wrote:

> Commit 265a5b7ee3eb ("kprobes/trace: Fix kprobe selftest for gcc 4.6")
> has added __used attribute to kprobe_trace_selftest_target to ensure
> that the method is listed in kallsyms table.
> 
> However, even though the method remains in the kernel image, the actual
> call is optimised away as there are no side efects and the return value
> is never checked.

Nice catch :)

> 
> Add a return value check and a 'noinline' attribute to ensure that an
> inlined copy of the method is not used by the caller. Also add checks
> that verify that the kprobe was really hit, as at the moment the tests
> show positive results despite the test method being optimised away.
> 
> Finally, add __init annotations to find_trace_probe_file() and
> kprobe_trace_selftest_target() as they are only called from within an
> __init method.

Right.

Looks good to me.

Acked-by: Masami Hiramatsu 

Thanks!

> 
> Signed-off-by: Marcin Nowakowski 
> ---
>  kernel/trace/trace_kprobe.c | 28 +++-
>  1 file changed, 23 insertions(+), 5 deletions(-)
> 
>  v2: no changes
> 
> diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
> index a2af1bc..a133ecd 100644
> --- a/kernel/trace/trace_kprobe.c
> +++ b/kernel/trace/trace_kprobe.c
> @@ -1361,18 +1361,18 @@ fs_initcall(init_kprobe_trace);
>  
>  
>  #ifdef CONFIG_FTRACE_STARTUP_TEST
> -
>  /*
>   * The "__used" keeps gcc from removing the function symbol
> - * from the kallsyms table.
> + * from the kallsyms table. 'noinline' makes sure that there
> + * isn't an inlined version used by the test method below
>   */
> -static __used int kprobe_trace_selftest_target(int a1, int a2, int a3,
> -int a4, int a5, int a6)
> +static __used __init noinline int
> +kprobe_trace_selftest_target(int a1, int a2, int a3, int a4, int a5, int a6)
>  {
>   return a1 + a2 + a3 + a4 + a5 + a6;
>  }
>  
> -static struct trace_event_file *
> +static struct __init trace_event_file *
>  find_trace_probe_file(struct trace_kprobe *tk, struct trace_array *tr)
>  {
>   struct trace_event_file *file;
> @@ -1450,12 +1450,25 @@ static __init int kprobe_trace_self_tests_init(void)
>  
>   ret = target(1, 2, 3, 4, 5, 6);
>  
> + /*
> +  * Not expecting an error here, the check is only to prevent the
> +  * optimizer from removing the call to target() as otherwise there
> +  * are no side-effects and the call is never performed.
> +  */
> + if (ret != 21)
> + warn++;
> +
>   /* Disable trace points before removing it */
>   tk = find_trace_kprobe("testprobe", KPROBE_EVENT_SYSTEM);
>   if (WARN_ON_ONCE(tk == NULL)) {
>   pr_warn("error on getting test probe.\n");
>   warn++;
>   } else {
> + if (trace_kprobe_nhit(tk) != 1) {
> + pr_warn("incorrect number of testprobe hits\n");
> + warn++;
> + }
> +
>   file = find_trace_probe_file(tk, top_trace_array());
>   if (WARN_ON_ONCE(file == NULL)) {
>   pr_warn("error on getting probe file.\n");
> @@ -1469,6 +1482,11 @@ static __init int kprobe_trace_self_tests_init(void)
>   pr_warn("error on getting 2nd test probe.\n");
>   warn++;
>   } else {
> + if (trace_kprobe_nhit(tk) != 1) {
> + pr_warn("incorrect number of testprobe2 hits\n");
> + warn++;
> + }
> +
>   file = find_trace_probe_file(tk, top_trace_array());
>   if (WARN_ON_ONCE(file == NULL)) {
>   pr_warn("error on getting probe file.\n");
> -- 
> 2.7.4
> 


-- 
Masami Hiramatsu 


Re: [LKP] [ext4] e2ae766c1b: BUG:sleeping_function_called_from_invalid_context_at_kernel/locking/rwsem.c

2016-12-12 Thread Huang, Ying
Jan Kara  writes:

> On Mon 12-12-16 18:13:21, kernel test robot wrote:
>> FYI, we noticed the following commit:
>> 
>> commit: e2ae766c1b030271b5099b25674e2131d1d1e8c1 ("ext4: convert DAX faults 
>> to iomap infrastructure")
>> https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git dev
>> 
>> in testcase: nvml
>> with following parameters:
>> 
>>  group: vmem
>>  test: pmem
>>  nr_pmem: 1
>>  fs: ext4
>>  mount_option: dax
>> 
>> 
>> 
>> on test machine: 64 threads Intel(R) Xeon(R) CPU E5-4650 0 @ 2.70GHz with 
>> 64G memory
>> 
>> caused below changes:
>> 
>> 
>> ++++
>> || 96f8ba3dd6 | e2ae766c1b |
>> ++++
>> | boot_successes | 2  | 2  |
>> | boot_failures  | 2  | 2  |
>> | BUG:kernel_hang_in_test_stage  | 2  ||
>> | WARNING:at_fs/sysfs/dir.c:#sysfs_warn_dup  | 0  | 2  |
>> | calltrace:parport_pc_init  | 0  | 2  |
>> | calltrace:SyS_finit_module | 0  | 2  |
>> | WARNING:at_lib/kobject.c:#kobject_add_internal | 0  | 2  |
>> ++++
>> 
>> 
>> 
>> user  :notice: [  325.592182] vmem_aligned_alloc/TEST1: SETUP 
>> (check/pmem/debug)
>> 
>> user  :notice: [  325.603973] vmem_aligned_alloc/TEST1: START: 
>> vmem_aligned_alloc
>> kern  :err   : [  325.608906] BUG: sleeping function called from invalid 
>> context at kernel/locking/rwsem.c:51
>> kern  :err   : [  325.608908] in_atomic(): 1, irqs_disabled(): 0, pid: 
>> 24813, name: vmem_aligned_al
>> kern  :warn  : [  325.608914] CPU: 44 PID: 24813 Comm: vmem_aligned_al 
>> Tainted: G   O4.9.0-rc4-00045-ge2ae766 #1
>> kern  :warn  : [  325.608916] Hardware name: Intel Corporation LH 
>> Pass/S4600LH, BIOS SE5C600.86B.99.02.1047.032320122259 03/23/2012
>> kern  :warn  : [  325.608922]  c9002c1f7be0
>> kern  :warn  : [  325.608923]  81466af9
>> kern  :warn  : [  325.608924]  880fea2425c0
>
> I think this is actually a bug introduced by Ross' PMD support. Attached
> patch should fix it. Ross, can you check it please?

Hi, Jan

Could you provide a git tree commit for me to test it?  If you want it
to be tested by 0day.

Best Regards,
Huang, Ying

>   Honza


Re: [RFC][PATCHv5 6/7] printk: use printk_safe buffers in printk

2016-12-12 Thread Sergey Senozhatsky
On (12/12/16 17:30), Petr Mladek wrote:
> On Thu 2016-12-01 22:55:45, Sergey Senozhatsky wrote:
> > Use printk_safe per-CPU buffers in printk recursion-prone blocks:
> > -- around logbuf_lock protected sections in vprintk_emit() and
> >console_unlock()
> > -- around down_trylock_console_sem() and up_console_sem()
> > 
> > Note that this solution addresses deadlocks caused by printk()
> > recursive calls only. That is vprintk_emit() and console_unlock().
> > 
> > Another thing to note is that we now keep lockdep enabled in printk,
> > because we are protected against the printk recursion caused by lockdep
> > in vprintk_emit() by the printk-safe mechanism - we first switch to
> > per-CPU buffers and only then access the deadlock-prone locks.
> > 
> > Signed-off-by: Sergey Senozhatsky 
> 
> Looks fine and safe to me.
> 
> Reviewed-by: Petr Mladek 

thanks.

-ss


Re: [RFC][PATCHv5 7/7] printk: remove zap_locks() function

2016-12-12 Thread Sergey Senozhatsky
On (12/12/16 17:37), Petr Mladek wrote:
> On Thu 2016-12-01 22:55:46, Sergey Senozhatsky wrote:
> > We use printk-safe now which makes printk-recursion detection code
> > in vprintk_emit() unreachable. The tricky thing here is that, apart
> > from detecting and reporting printk recursions, that code also used
> > to zap_locks() in case of panic() from the same CPU. However,
> > zap_locks() does not look to be needed anymore:
> > 
> > 1) Since commit 08d78658f393 ("panic: release stale console lock to
> >always get the logbuf printed out") panic flushing of `logbuf' to
> >console ignores the state of `console_sem' by doing
> > panic()
> > console_trylock();
> > console_unlock();
> > 
> > 2) Since commit cf9b1106c81c ("printk/nmi: flush NMI messages on the
> >system panic") panic attempts to zap the `logbuf_lock' spin_lock to
> >successfully flush nmi messages to `logbuf'.
> > 
> > Basically, it seems that we either already do what zap_locks() used to
> > do but in other places or we ignore the state of the lock. The only
> > reaming difference is that we don't re-init the console semaphore in
> > printk_safe_flush_on_panic(), but this is not necessary because we
> > don't call console drivers from printk_safe_flush_on_panic() due to
> > the fact that we are using a deferred printk() version (as was
> > suggested by Petr Mladek).
> > 
> > Signed-off-by: Sergey Senozhatsky 
> 
> I like this patch. The code is unused after protecting the section
> by printk_safe_enter()/exit(). And also the panic mode is handled
> by the commits mentioned above.

and the scenario that code tried to address was super-tiny.
basically, a recursion from vscnprintf()/log_output() every 30
seconds (zap_locks() timeout):

if (unlikely(logbuf_cpu == this_cpu)) {
zap_locks();
}

raw_spin_lock(_lock);
logbuf_cpu = this_cpu;

text_len = vscnprintf(text, sizeof(textbuf), fmt, args);
kern_level = printk_get_level(text));
log_output(facility, level, lflags, dict, dictlen, text, text_len);

logbuf_cpu = UINT_MAX;
raw_spin_unlock(_lock);

now we cover a much bigger scope.


> Reviewed-by: Petr Mladek 

thanks.

-ss


  1   2   3   4   5   6   7   8   >