I need your assistance to invest!!!
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
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(&sg[0], hdr, sizeof(hdr));
> - sg_set_buf(&sg[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
[...] >>> + >>> +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
>> 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
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(&audit_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
>> 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 2/2] usb: dwc3: core: Support the dwc3 host suspend/resume
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(&dwc->lock, flags);
+ dwc3_gadget_suspend(dwc);
+ spin_unlock_irqrestore(&dwc->lock, flags);
+ break;
case USB_DR_MODE_OTG:
+ ret = dwc3_host_suspend(dwc);
+ if (ret)
+ return ret;
+
spin_lock_irqsave(&dwc->lock, flags);
dwc3_gadget_suspend(dwc);
spin_unlock_irqrestore(&dwc->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(&dwc->lock, flags);
+ dwc3_gadget_resume(dwc);
+ spin_unlock_irqrestore(&dwc->lock, flags);
+ break;
case USB_DR_MODE_OTG:
+ ret = dwc3_host_resume(dwc);
+ if (ret)
+ return ret;
+
spin_lock_irqsave(&dwc->lock, flags);
dwc3_gadget_resume(dwc);
spin_unlock_irqrestore(&dwc->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(&dwc->xhci->dev));
platform_device_unregister(dwc->xhci);
}
+
+int dwc3_host_suspend(struct dwc3 *dwc)
+{
+ struct device *xhci = &dwc->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 = &dwc->xhci->dev;
+
+ /* Resume the xHCI device synchronously. */
+ return pm_runtime_get_sync(xhci);
+}
--
1.7.9.5
[PATCH v5 1/2] usb: host: plat: Enable xhci plat runtime PM
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(&pdev->dev);
+ pm_runtime_set_active(&pdev->dev);
+ pm_runtime_enable(&pdev->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->dev);
+ pm_runtime_put_noidle(&dev->dev);
+ pm_runtime_disable(&dev->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 (&xhci_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 = &xhci_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
Re: epoll_wait inaccurate timeout
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
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);
goto try_fallback;
diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
inde
Re: [PATCH] Input: ar1021-i2c - fix too long name in driver's device table
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
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
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
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"
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
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
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
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
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
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
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&low 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(&hsotg->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, &hsotg->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(&dwc2_hc_driver, hsotg->dev, dev_name(hsotg->dev));
if (!hcd)
goto error1;
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 8e1728b..17eb5fd 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -85,6 +85,7 @@ static const struct dwc2_core
[RFC][PATCH 3/5] usb: dwc2: Force port resume on switching to device mode
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
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 f
[GIT PULL] xen: features and fixes for 4.10 rc0
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 EVTCHNOP_st
Re: [PATCH 0/4] UEFI: EFI_MEMORY_ATTRIBUTES_TABLE support for x86
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
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,
&iattr.ia_mode, &acl);
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
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
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 @ > +expression mod, name, dev, gfp, drv, cb; > +position p; > +@@ > + > +( > +*request_firmware_nowait@p(mod, false
Re: [PATCH v3 1/4] pinctrl: aspeed: Read and write bits in LPC and GFX controllers
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 pinctrl/pinmux driver using o
linux-next: Tree for Dec 13
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/mas
[PATCH v2] btrfs: limit async_work allocation and worker func duration
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(&wq->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(&delayed_root->items) < BTRFS_DELAYED_BACKGROUND)
+ if (atomic_read(&delayed_root->items) < BTRFS_DELA
[PATCH v2] kasan: Support for r/w instrumentation control
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
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
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 Le
[PATCH RFC] [media] m5mols: add missing dependency on VIDEO_IR_I2C
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
---
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??
Are you in need of a loan? Apply for more details.
[PATCH] [media] m5mols: set usleep_range delta greater 0
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 --- 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 *)&val, 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
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(&audit_cmd_mutex);
> > + auditd_reset();
> > + mutex_unlock(&audit_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
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
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(&audit_cmd_mutex);
> > + auditd_reset();
> > + mutex_unlock(&audit_cmd_mutex);
> > + }
> > }
> >
> > return rc;
> > @@ -579,7 +587,9 @@ static int kauditd_thread(void *dummy)
> >
> > auditd = 0;
> > if (AUDITD_BAD(rc, reschedule)) {
> > + mutex_lock(&audit_cmd_mutex);
> > auditd_reset();
> > + mutex_unlock(&audit_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(&audit_cmd_mutex);
> > auditd_reset();
> > + mutex_unlock(&audit_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(&audit_cmd_mutex);
> > auditd_reset();
> > +
> > mutex_unlock(&audit_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;
> > - if (!new_pid)
> > +
Re: [PATCH v3 4/6] mfd: dt: Add bindings for the Aspeed LPC Host Controller (LHC)
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
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
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
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
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
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 &ntb_dev_ops.
> * @ctx: See &ntb_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
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 > + initialization is unsupported) > + 2) Map outboun
RE: [PATCH v2 8/9] NTB: Add PCIe Gen4 link speed
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
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(&ntb->ctx_lock, irqflags);
> + {
> + if (ntb->ctx_ops && ntb->ctx_ops->msg_event)
> + ntb->ctx_ops->msg_event(ntb->ctx);
> + }
> + spin_unlock_irqrestore(&ntb->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 && */
> /* !ops->peer_spad_read == !ops->spa
RE: [PATCH v2 5/9] NTB: Alter Scratchpads API to support multi-ports devices
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 +
> ndev->peer_reg-
RE: [PATCH v2 4/9] NTB: Alter MW API to support multi-ports devices
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)
> + return -EINV
RE: [PATCH v2 1/9] NTB: Make link-state API being declared first
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 (ndev->peer_sta & AMD_PEER_D0_EV
RE: [PATCH v2 3/9] NTB: Alter link-state API to support multi-port devices
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. Returning from this call must
> + * indicate that
RE: [PATCH v2 2/9] NTB: Add indexed ports NTB API
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 encourage
other PRI/SEC drivers t
Re: [PATCH 0/8] Sparse warning fixes in Lustre.
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)
> 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
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 --- 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'
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
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 --- 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
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?
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 (1662
Re: [PATCH v2 2/2] dt-bindings: Add DT bindings info for FlexRM ring manager
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 = <&gic_its 0x7f00>;
>> + #mbox-cells = <3>;
>> +};
>> +
>> +crypto_client {
>> + ...
>> + mboxes = <&crypto_mbox 0 0x1 0x>,
>> + <&crypto_mbox 1 0x1 0x>,
>> + <&crypto_mbox 16 0x1 0x>,
>> + <&crypto_mbox 17 0x1 0x>,
>> + <&crypto_mbox 30 0x1 0x>,
>> + <&crypto_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 = <&crypto_mbox 0 0x1 0x>,
<&crypto_mbox 1 0x1 0x>,
<&crypto_mbox 16 0x1 0x>,
<&crypto_mbox 17 0x1 0x>,
<&crypto_mbox 30 0x1 0x>,
<&crypto_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
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
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
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
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
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
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 - - do 64 bit correctly - - don't depend on order of union - - get rid of ASSERT(), use BUG() instead but only where necessary - looks like most aren't really useful - - no new SIOCDEVPRIV
Re: [PATCH v6] pwm: add pwm driver for HiSilicon BVT SOCs
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 = <&crg_ctrl HI3516CV300_PWM_CLK>;
> + resets = <&crg_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
Re: [PATCH] selftests: ftrace: Shift down default message verbosity
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
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
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
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
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
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 depends on report@ +p << r1.p; +@@ + +coccilib.report.print_report(p[0], "WARNING: please check if driver really
[PATCH 2/5] selftests: firmware: send expected errors to /dev/null
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
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
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 characters. + +It is r
[PATCH 0/5] firmware: doc revamp
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
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
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
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
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: r
[PATCH v3] llist: Clarify comments about when locking is needed
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
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
---
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
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
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)
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
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
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
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
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
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 = <&topckgen CLK_TOP_ETHIF_SEL>,
+<ðsys CLK_ETHSYS_CRYPTO>;
+ clock-names = "ethif","cryp";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_ETH>;
+ };
--
1.9.1
[PATCH v2 1/2] Add crypto driver support for some MediaTek chips
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 is a set of hardware instructions(command token)
[PATCH v2 0/2] Add MediaTek crypto accelerator driver
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
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(&tk->tp.call), nhit,
> +trace_event_name(&tk->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
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
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
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
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(&logbuf_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(&logbuf_lock);
now we cover a much bigger scope.
> Reviewed-by: Petr Mladek
thanks.
-ss
