[PATCH] usb: dwc2: fix transfer stop programming for out endpoint
From: "Du, Changbin"
To stop an out endpoint, software should set sets the Global OUT NAK,
but not the Global Non-periodic IN NAK. This driver bug leads the out-ep
failed be in disabled state with below error.
dwc2_hsotg_ep_stop_xfr: timeout DOEPCTL.EPDisable
Signed-off-by: Du, Changbin
---
drivers/usb/dwc2/gadget.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 0abf73c..92a182f 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2911,15 +2911,15 @@ static void dwc2_hsotg_ep_stop_xfr(struct dwc2_hsotg
*hsotg,
"%s: timeout DIEPINT.NAKEFF\n", __func__);
} else {
/* Clear any pending nak effect interrupt */
- dwc2_writel(GINTSTS_GINNAKEFF, hsotg->regs + GINTSTS);
+ dwc2_writel(GINTSTS_GOUTNAKEFF, hsotg->regs + GINTSTS);
- __orr32(hsotg->regs + DCTL, DCTL_SGNPINNAK);
+ __orr32(hsotg->regs + DCTL, DCTL_SGOUTNAK);
/* Wait for global nak to take effect */
if (dwc2_hsotg_wait_bit_set(hsotg, GINTSTS,
- GINTSTS_GINNAKEFF, 100))
+ GINTSTS_GOUTNAKEFF, 100))
dev_warn(hsotg->dev,
- "%s: timeout GINTSTS.GINNAKEFF\n", __func__);
+ "%s: timeout GINTSTS.GOUTNAKEFF\n", __func__);
}
/* Disable ep */
@@ -2944,7 +2944,7 @@ static void dwc2_hsotg_ep_stop_xfr(struct dwc2_hsotg
*hsotg,
/* TODO: Flush shared tx fifo */
} else {
/* Remove global NAKs */
- __bic32(hsotg->regs + DCTL, DCTL_SGNPINNAK);
+ __bic32(hsotg->regs + DCTL, DCTL_SGOUTNAK);
}
}
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 0/1] atm: solos-pci: Replace simple_strtol by kstrtoint
Hello Change since v3 - rework the test logic with ver/err Change since v2 - Invert a test logic Change since v1 - Always return error code from kstrtox. LABBE Corentin (1): atm: solos-pci: Replace simple_strtol by kstrtoint drivers/atm/solos-pci.c | 28 +--- 1 file changed, 17 insertions(+), 11 deletions(-) -- 2.4.10 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/1] atm: solos-pci: Replace simple_strtol by kstrtoint
The simple_strtol function is obsolete.
This patch replace it by kstrtoint.
This will simplify code, since some error case not handled by
simple_strtol are handled by kstrtoint.
Signed-off-by: LABBE Corentin
---
drivers/atm/solos-pci.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/drivers/atm/solos-pci.c b/drivers/atm/solos-pci.c
index 3d7fb65..0c2b4ba0 100644
--- a/drivers/atm/solos-pci.c
+++ b/drivers/atm/solos-pci.c
@@ -347,8 +347,8 @@ static char *next_string(struct sk_buff *skb)
*/
static int process_status(struct solos_card *card, int port, struct sk_buff
*skb)
{
- char *str, *end, *state_str, *snr, *attn;
- int ver, rate_up, rate_down;
+ char *str, *state_str, *snr, *attn;
+ int ver, rate_up, rate_down, err;
if (!card->atmdev[port])
return -ENODEV;
@@ -357,7 +357,11 @@ static int process_status(struct solos_card *card, int
port, struct sk_buff *skb
if (!str)
return -EIO;
- ver = simple_strtol(str, NULL, 10);
+ err = kstrtoint(str, 10, );
+ if (err) {
+ dev_warn(>dev->dev, "Unexpected status interrupt
version\n");
+ return err;
+ }
if (ver < 1) {
dev_warn(>dev->dev, "Unexpected status interrupt version
%d\n",
ver);
@@ -373,16 +377,16 @@ static int process_status(struct solos_card *card, int
port, struct sk_buff *skb
return 0;
}
- rate_down = simple_strtol(str, , 10);
- if (*end)
- return -EIO;
+ err = kstrtoint(str, 10, _down);
+ if (err)
+ return err;
str = next_string(skb);
if (!str)
return -EIO;
- rate_up = simple_strtol(str, , 10);
- if (*end)
- return -EIO;
+ err = kstrtoint(str, 10, _up);
+ if (err)
+ return err;
state_str = next_string(skb);
if (!state_str)
@@ -417,7 +421,7 @@ static int process_command(struct solos_card *card, int
port, struct sk_buff *sk
struct solos_param *prm;
unsigned long flags;
int cmdpid;
- int found = 0;
+ int found = 0, err;
if (skb->len < 7)
return 0;
@@ -428,7 +432,9 @@ static int process_command(struct solos_card *card, int
port, struct sk_buff *sk
skb->data[6] != '\n')
return 0;
- cmdpid = simple_strtol(>data[1], NULL, 10);
+ err = kstrtoint(>data[1], 10, );
+ if (err)
+ return err;
spin_lock_irqsave(>param_queue_lock, flags);
list_for_each_entry(prm, >param_queue, list) {
--
2.4.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/rapl: Do not load in a guest
* Borislav Petkov wrote: > From: Borislav Petkov > > qemu/kvm doesn't support RAPL and RAPL doesn't have a CPUID feature bit > so check whether we're in a guest instead. So when a hypervisor starts supporting RAPL we'll disable the driver erroneously? Isn't there any better method to detect RAPL support? So in particular in drivers/powercap/intel_rapl.c there's an enumerated list of CPU models, which is used via a x86_match_cpu() call. That's still not ideal (it does not work on hypervisors for example), but even better would be to detect RAPL support in some other fashion, that does not rely on us statically enumerating CPU models that support it. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iwlwifi A-MSDU tx
Hi, On Fri, Dec 4, 2015 at 12:05 AM, Stefan Sperling wrote: > Hi Emmanuel, > > As part of implementing 802.11n support in OpenBSD I'm looking for > an AP which sends A-MSDUs. Preferrably under software control rather > than firmware. > > I found your iwlwifi A-MSDU patches at > http://marc.info/?l=linux-wireless=144553311122495=2 > and http://marc.info/?l=linux-wireless=144553311822496=2 > > Would these patches make it possible to run an AP with an 5300 or 7260 > card and send A-MSDUs? That would be great as I have the necessary hardware. 7260 will go. Not 5300. Note that this code simulates Tx TCP Csum offload. I did that to write the code while we still don't have the hardware that has this capability. But for testing purposes, it should do the work. The testing teams have reported that AP mode didn't work quite well with this and I haven't taken the time to look into yet, but if you see issues, please report them or even better: fix them :) > > Which Linux tree do these patches apply to? I've tried the following > but had no luck in getting these patches applied without rejects: > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git > Right. These patches had a long internal review cycle. They are now merge in our internal tree. You can find them in our internal tree [1] (backport based). I will push them soon in iwlwifi-next.git. [1] - https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/backport-iwlwifi.git/ Please read https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/core_release#how_to_install_the_driver. > Thanks, > Stefan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] Add __GFP_ZERO to alloc_cpumask_var_node() if ptr is zero
* Steven Rostedt wrote: > On Fri, 04 Dec 2015 12:05:12 +1030 > Rusty Russell wrote: > > > This is clever, but I would advise against such subtle code. We will never > > be > > able to remove this code once it is in. > > > > Would suggest making the non-CPUMASK_OFFSTACK stubs write garbage into the > > cpumasks instead, iff !(flags & __GFP_ZERO). > > I actually thought of the same thing, but thought it was a bit harsh. If > others > think that's a better solution, then I'll submit a patch to do that. That just makes things more fragile - 'garbage' will spread the breakage, and if the breakage is subtle, it will spread subtle breakage. So why not use a kzmalloc_node() [equivalent] call instead of kmalloc_node(), to make sure it's all zeroed instead of uninitialized? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A new, fast and "unbreakable" encryption algorithm
Ismail Kizir wrote: > What means "did not look random"? A plaintext consisting of repeated bytes (zero, or other values) eventually makes your algorithm go into a loop, which results in repeated bytes. > On the pictures, there is also an example of "full 0"(it appears red, > but it is full 0 bmp) example. > And it "looks" perfectly random. No, red is _not_ perfectly random. When I see a red picture, I have evidence that the plaintext was zeroes. Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] x86: ftrace: fix the comments for ftrace_modify_code_direct
There is no need to worry about module and __init text disappearing case, because that ftrace has a module notifier that is called when a module is being unloaded and before the text goes away and this code grabs the ftrace_lock mutex and removes the module functions from the ftrace list, such that it will no longer do any modifications to that module's text, the update to make functions be traced or not is done under the ftrace_lock mutex as well. And by now, __init section codes should not been modified by ftrace, because it is black listed in recordmcount.c and ignored by ftrace. Cc: Thomas Gleixner Cc: "H. Peter Anvin" Cc: x...@kernel.org Suggested-by: Steven Rostedt Signed-off-by: Li Bin --- arch/x86/kernel/ftrace.c | 13 ++--- 1 files changed, 6 insertions(+), 7 deletions(-) diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c index 311bcf3..c2987e8 100644 --- a/arch/x86/kernel/ftrace.c +++ b/arch/x86/kernel/ftrace.c @@ -106,13 +106,12 @@ ftrace_modify_code_direct(unsigned long ip, unsigned const char *old_code, unsigned char replaced[MCOUNT_INSN_SIZE]; /* -* Note: Due to modules and __init, code can -* disappear and change, we need to protect against faulting -* as well as code changing. We do this by using the -* probe_kernel_* functions. -* -* No real locking needed, this code is run through -* kstop_machine, or before SMP starts. +* Note: +* We are paranoid about modifying text, as if a bug were to happen, it +* could cause us to read or write to someplace that could cause harm. +* Carefully read and modify the code with aarch64_insn_*() which uses +* probe_kernel_*(), and make sure what we read is what we expected it +* to be before modifying it. */ /* read the text we want to modify */ -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb: gadget: make usb_ep_enable return -EBUSY if ep has already enabled
From: "Du, Changbin" When usb_ep_enable on a enabled ep, the configuration of the ep probably has changed. In this scenario, the ep configuration in hw should be reprogrammed by udc driver. Hence, it is better to return an error to inform the caller. Signed-off-by: Du, Changbin --- include/linux/usb/gadget.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h index d813bd2..89f9fdd 100644 --- a/include/linux/usb/gadget.h +++ b/include/linux/usb/gadget.h @@ -268,7 +268,7 @@ static inline int usb_ep_enable(struct usb_ep *ep) int ret; if (ep->enabled) - return 0; + return -EBUSY; ret = ep->ops->enable(ep, ep->desc); if (ret) -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] powerpc: ftrace: fix the comments for ftrace_modify_code
There is no need to worry about module and __init text disappearing case, because that ftrace has a module notifier that is called when a module is being unloaded and before the text goes away and this code grabs the ftrace_lock mutex and removes the module functions from the ftrace list, such that it will no longer do any modifications to that module's text, the update to make functions be traced or not is done under the ftrace_lock mutex as well. And by now, __init section codes should not been modified by ftrace, because it is black listed in recordmcount.c and ignored by ftrace. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: linuxppc-...@lists.ozlabs.org Suggested-by: Steven Rostedt Signed-off-by: Li Bin --- arch/powerpc/kernel/ftrace.c | 13 ++--- 1 files changed, 6 insertions(+), 7 deletions(-) diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c index 44d4d8e..c6452b2 100644 --- a/arch/powerpc/kernel/ftrace.c +++ b/arch/powerpc/kernel/ftrace.c @@ -47,13 +47,12 @@ ftrace_modify_code(unsigned long ip, unsigned int old, unsigned int new) unsigned int replaced; /* -* Note: Due to modules and __init, code can -* disappear and change, we need to protect against faulting -* as well as code changing. We do this by using the -* probe_kernel_* functions. -* -* No real locking needed, this code is run through -* kstop_machine, or before SMP starts. +* Note: +* We are paranoid about modifying text, as if a bug were to happen, it +* could cause us to read or write to someplace that could cause harm. +* Carefully read and modify the code with aarch64_insn_*() which uses +* probe_kernel_*(), and make sure what we read is what we expected it +* to be before modifying it. */ /* read the text we want to modify */ -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] sh: ftrace: fix the comments for ftrace_modify_code
There is no need to worry about module and __init text disappearing case, because that ftrace has a module notifier that is called when a module is being unloaded and before the text goes away and this code grabs the ftrace_lock mutex and removes the module functions from the ftrace list, such that it will no longer do any modifications to that module's text, the update to make functions be traced or not is done under the ftrace_lock mutex as well. And by now, __init section codes should not been modified by ftrace, because it is black listed in recordmcount.c and ignored by ftrace. Cc: linux...@vger.kernel.org Suggested-by: Steven Rostedt Signed-off-by: Li Bin --- arch/sh/kernel/ftrace.c | 13 ++--- 1 files changed, 6 insertions(+), 7 deletions(-) diff --git a/arch/sh/kernel/ftrace.c b/arch/sh/kernel/ftrace.c index 079d70e..b696f92 100644 --- a/arch/sh/kernel/ftrace.c +++ b/arch/sh/kernel/ftrace.c @@ -212,13 +212,12 @@ static int ftrace_modify_code(unsigned long ip, unsigned char *old_code, unsigned char replaced[MCOUNT_INSN_SIZE]; /* -* Note: Due to modules and __init, code can -* disappear and change, we need to protect against faulting -* as well as code changing. We do this by using the -* probe_kernel_* functions. -* -* No real locking needed, this code is run through -* kstop_machine, or before SMP starts. +* Note: +* We are paranoid about modifying text, as if a bug were to happen, it +* could cause us to read or write to someplace that could cause harm. +* Carefully read and modify the code with aarch64_insn_*() which uses +* probe_kernel_*(), and make sure what we read is what we expected it +* to be before modifying it. */ /* read the text we want to modify */ -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb: gadget: forbid queuing request to a disabled ep
From: "Du, Changbin"
Queue a request to disabled ep doesn't make sense, and induce caller
make mistakes.
Here is a example for the android mtp gadget function driver. A mem
corruption can happen on below senario.
1) On disconnect, mtp driver disable its EPs,
2) During send_file_work and receive_file_work, mtp queues a request
to ep. (The mtp driver need improve its synchronization logic!)
3) mtp_function_unbind is invoked and all mtp requests are freed.
4) when udc process the request queued on step 2, will cause kernel
NULL pointer dereference exception.
Signed-off-by: Du, Changbin
---
This patch is seprated from below patches because gadget layer has
added the 'enabled' flag in v4.4. so abandon it and submit new one.
[PATCH 0/2] Two fix for dwc2 gadget driver
usb: dwc2: add ep enabled flag to avoid double enable/disable
usb: dwc2: forbid queuing request to a disabled ep
---
include/linux/usb/gadget.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 3d583a1..d813bd2 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -402,6 +402,9 @@ static inline void usb_ep_free_request(struct usb_ep *ep,
static inline int usb_ep_queue(struct usb_ep *ep,
struct usb_request *req, gfp_t gfp_flags)
{
+ if (!ep->enabled)
+ return -ESHUTDOWN;
+
return ep->ops->queue(ep, req, gfp_flags);
}
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] metag: ftrace: fix the comments for ftrace_modify_code
There is no need to worry about module and __init text disappearing case, because that ftrace has a module notifier that is called when a module is being unloaded and before the text goes away and this code grabs the ftrace_lock mutex and removes the module functions from the ftrace list, such that it will no longer do any modifications to that module's text, the update to make functions be traced or not is done under the ftrace_lock mutex as well. And by now, __init section codes should not been modified by ftrace, because it is black listed in recordmcount.c and ignored by ftrace. Cc: James Hogan Cc: linux-me...@vger.kernel.org Suggested-by: Steven Rostedt Signed-off-by: Li Bin --- arch/metag/kernel/ftrace.c | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/metag/kernel/ftrace.c b/arch/metag/kernel/ftrace.c index ed1d685..e5d71b1 100644 --- a/arch/metag/kernel/ftrace.c +++ b/arch/metag/kernel/ftrace.c @@ -54,12 +54,12 @@ static int ftrace_modify_code(unsigned long pc, unsigned char *old_code, unsigned char replaced[MCOUNT_INSN_SIZE]; /* -* Note: Due to modules and __init, code can -* disappear and change, we need to protect against faulting -* as well as code changing. -* -* No real locking needed, this code is run through -* kstop_machine. +* Note: +* We are paranoid about modifying text, as if a bug were to happen, it +* could cause us to read or write to someplace that could cause harm. +* Carefully read and modify the code with aarch64_insn_*() which uses +* probe_kernel_*(), and make sure what we read is what we expected it +* to be before modifying it. */ /* read the text we want to modify */ -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] ftrace: fix ftrace misleading comments for arch using it
Fix the following similar misleading comments of ftrace for arch ia64/metag/powerpc/sh/x86: Note: Due to modules and __init, code can disappear and change, we need to protect against faulting as well as code changing. We do this by using the probe_kernel_* functions. No real locking needed, this code is run through kstop_machine, or before SMP starts. Cc: Tony Luck Cc: Fenghua Yu Cc: linux-i...@vger.kernel.org Cc: James Hogan Cc: linux-me...@vger.kernel.org Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: linuxppc-...@lists.ozlabs.org Cc: linux...@vger.kernel.org Cc: Thomas Gleixner "Cc: H. Peter Anvin" Cc: x...@kernel.org Li Bin (5): ia64: ftrace: fix the comments for ftrace_modify_code metag: ftrace: fix the comments for ftrace_modify_code powerpc: ftrace: fix the comments for ftrace_modify_code sh: ftrace: fix the comments for ftrace_modify_code x86: ftrace: fix the comments for ftrace_modify_code_direct arch/ia64/kernel/ftrace.c| 13 ++--- arch/metag/kernel/ftrace.c | 12 ++-- arch/powerpc/kernel/ftrace.c | 13 ++--- arch/sh/kernel/ftrace.c | 13 ++--- arch/x86/kernel/ftrace.c | 13 ++--- 5 files changed, 30 insertions(+), 34 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] ia64: ftrace: fix the comments for ftrace_modify_code
There is no need to worry about module and __init text disappearing case, because that ftrace has a module notifier that is called when a module is being unloaded and before the text goes away and this code grabs the ftrace_lock mutex and removes the module functions from the ftrace list, such that it will no longer do any modifications to that module's text, the update to make functions be traced or not is done under the ftrace_lock mutex as well. And by now, __init section codes should not been modified by ftrace, because it is black listed in recordmcount.c and ignored by ftrace. Cc: Tony Luck Cc: Fenghua Yu Cc: linux-i...@vger.kernel.org Suggested-by: Steven Rostedt Signed-off-by: Li Bin --- arch/ia64/kernel/ftrace.c | 13 ++--- 1 files changed, 6 insertions(+), 7 deletions(-) diff --git a/arch/ia64/kernel/ftrace.c b/arch/ia64/kernel/ftrace.c index 3b0c2aa..a48a3f4 100644 --- a/arch/ia64/kernel/ftrace.c +++ b/arch/ia64/kernel/ftrace.c @@ -97,13 +97,12 @@ ftrace_modify_code(unsigned long ip, unsigned char *old_code, unsigned char replaced[MCOUNT_INSN_SIZE]; /* -* Note: Due to modules and __init, code can -* disappear and change, we need to protect against faulting -* as well as code changing. We do this by using the -* probe_kernel_* functions. -* -* No real locking needed, this code is run through -* kstop_machine, or before SMP starts. +* Note: +* We are paranoid about modifying text, as if a bug were to happen, it +* could cause us to read or write to someplace that could cause harm. +* Carefully read and modify the code with aarch64_insn_*() which uses +* probe_kernel_*(), and make sure what we read is what we expected it +* to be before modifying it. */ if (!do_check) -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mtd, nand, omap2: parse cmdline partition fail
On Fri, Dec 4, 2015 at 7:48 AM, Heiko Schocher wrote:
> Hello Frans,
>
> I just tried current mainline kernel:
> commit 2255702db4014d1c69d6037ed7bdad2d2e271985
> Merge: 9e5d25e c86576e
> Author: Linus Torvalds
> Date: Mon Nov 30 16:06:44 2015 -0800
>
> Merge tag 'mn10300-for-linus-v4.4-rc4' of
> git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
>
> on an am3517 based board (mainlining soon). And with your commit:
> commit 853f1c58c4b2: mtd: nand: omap2: show parent device structure in sysfs
>
> MTD partitions from cmdline are not longer detected:
>
> [2.087305] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xcc
> [2.094097] nand: Micron MT29F4G16ABADAWP
> [2.098303] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB
> size: 64
> [2.106296] nand: WARNING: MT29F4G16ABADAWP: the ECC used on your system
> is too weak compared to the one required by the NAND chip
> [2.118674] MT29F4G16ABADAWP: 'partitions' subnode not found on
> /ocp/gpmc@6e00/nand@0,0. Trying to parse direct subnodes as partitions.
> [...]
>
> before this patch it worked:
> [2.307444] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xcc
> [2.314092] nand: Micron MT29F4G16ABADAWP
> [2.318348] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB
> size: 64
> [2.326331] nand: WARNING: omap2-nand.0: the ECC used on your system is
> too weak compared to the one required by the NAND chip
> [2.338336] 5 cmdlinepart partitions found on MTD device omap2-nand.0
> [2.345129] Creating 5 MTD partitions on "omap2-nand.0":
> [2.350704] 0x-0x0008 : "MLO"
> [2.366877] 0x0008-0x0018 : "u-boot"
> [2.379179] 0x0018-0x001c : "env1"
> [2.390627] 0x001c-0x0020 : "env2"
> [2.402255] 0x0020-0x2000 : "common_data"
>
> Reason is taht the mtd->name has changed from "omap2-nand.0" to the
> nand chip name ...
>
> If I revert this part from the patch
>
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index 93f664c..28dcf66 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -1685,6 +1685,7 @@ static int omap_nand_probe(struct platform_device
> *pdev)
> info->ecc_opt = pdata->ecc_opt;
> mtd = >mtd;
> mtd->priv = >nand;
> + mtd->name = dev_name(>dev);
> mtd->dev.parent = >dev;
> nand_chip = >nand;
> nand_chip->ecc.priv = NULL;
>
> It works again ...
>
> So the question is, is it intended to change the "mtd->name"?
That's definitely not intended. The expectation with this patch is
that nothing really changes, except that a parent device link is
available in sysfs. For the name this patch depends on 807f16d4db956
("mtd: core: set some defaults when dev.parent is set") which does
something like:
if (mtd->dev.parent) {
if (!mtd->name)
mtd->name = dev_name(mtd->dev.parent);
}
The fact that this produces different names for you is slightly
surprising to me, unless mtd->name is already set to something by the
time it reaches add_mtd_device(). Or I overlooked something, which is
entirely plausible as well.
So effectively this should be the same as doing:
mtd->dev.parent = >dev;
mtd->name = dev_name(mtd->dev.parent);
> But wondering, if there are two or more identical nand chips in the
> system, they will have the same mtd->name ... which seems buggy to me...
Agree.
Thanks,
Frans
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Input: psmouse - clean up Cypress probe
Hi,
On 04-12-15 00:56, Dmitry Torokhov wrote:
When Cypress protocol support is disabled cypress_init() is a stub that
always returns -ENOSYS, so there is not point in testing for
CONFIG_MOUSE_PS2_CYPRESS after we decided that we are dealing with a
Cypress device. Also, we should only be calling cypress_detect() when
set_properties argument is "true", like with other protocols.
There is a slight change in behavior to make follow-up patches more
uniform: when we detect Cypress but its initialization fails, instead of
immediately returning PSMOUSE_PS2 protocol we now continue trying
IntelliMouse [Explorer]. Given that Cypress devices only have issue with
Sentelic probes probing Imtellimouse should be safe.
Signed-off-by: Dmitry Torokhov
Thanks, looks good to me:
Reviewed-by: Hans de Goede
Regards,
Hans
---
drivers/input/mouse/psmouse-base.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/input/mouse/psmouse-base.c
b/drivers/input/mouse/psmouse-base.c
index c2bd866..978ba0b 100644
--- a/drivers/input/mouse/psmouse-base.c
+++ b/drivers/input/mouse/psmouse-base.c
@@ -836,19 +836,15 @@ static int psmouse_extensions(struct psmouse *psmouse,
* Trackpads.
*/
if (max_proto > PSMOUSE_IMEX &&
- cypress_detect(psmouse, set_properties) == 0) {
- if (IS_ENABLED(CONFIG_MOUSE_PS2_CYPRESS)) {
- if (cypress_init(psmouse) == 0)
- return PSMOUSE_CYPRESS;
-
- /*
-* Finger Sensing Pad probe upsets some modules of
-* Cypress Trackpad, must avoid Finger Sensing Pad
-* probe if Cypress Trackpad device detected.
-*/
- return PSMOUSE_PS2;
- }
+ psmouse_do_detect(cypress_detect, psmouse, set_properties) == 0) {
+ if (!set_properties || cypress_init(psmouse) == 0)
+ return PSMOUSE_CYPRESS;
+ /*
+* Finger Sensing Pad probe upsets some modules of
+* Cypress Trackpad, must avoid Finger Sensing Pad
+* probe if Cypress Trackpad device detected.
+*/
max_proto = PSMOUSE_IMEX;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] thermal: rcar: enable to use thermal-zone on DT
Hi Manish
> > +static int rcar_thermal_of_get_temp(void *data, int *temp)
> > +{
> > + struct rcar_thermal_priv *priv = data;
> > +
> > + *temp = rcar_thermal_get_current_temp(priv);
> > +
> > + return 0;
> > +}
> > +
> > +static int rcar_thermal_get_temp(struct thermal_zone_device *zone, int
> > *temp)
> > +{
> > + struct rcar_thermal_priv *priv = rcar_zone_to_priv(zone);
> > +
> > + *temp = rcar_thermal_get_current_temp(priv);
> > +
> > return 0;
> > }
> >
>
> Above two function, always returns 0. Can it possible to handle error
> and log some messages.
Thanks. Will try in v2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
mtd, nand, omap2: parse cmdline partition fail
Hello Frans, I just tried current mainline kernel: commit 2255702db4014d1c69d6037ed7bdad2d2e271985 Merge: 9e5d25e c86576e Author: Linus Torvalds Date: Mon Nov 30 16:06:44 2015 -0800 Merge tag 'mn10300-for-linus-v4.4-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging on an am3517 based board (mainlining soon). And with your commit: commit 853f1c58c4b2: mtd: nand: omap2: show parent device structure in sysfs MTD partitions from cmdline are not longer detected: [2.087305] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xcc [2.094097] nand: Micron MT29F4G16ABADAWP [2.098303] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 [2.106296] nand: WARNING: MT29F4G16ABADAWP: the ECC used on your system is too weak compared to the one required by the NAND chip [2.118674] MT29F4G16ABADAWP: 'partitions' subnode not found on /ocp/gpmc@6e00/nand@0,0. Trying to parse direct subnodes as partitions. [...] before this patch it worked: [2.307444] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xcc [2.314092] nand: Micron MT29F4G16ABADAWP [2.318348] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 [2.326331] nand: WARNING: omap2-nand.0: the ECC used on your system is too weak compared to the one required by the NAND chip [2.338336] 5 cmdlinepart partitions found on MTD device omap2-nand.0 [2.345129] Creating 5 MTD partitions on "omap2-nand.0": [2.350704] 0x-0x0008 : "MLO" [2.366877] 0x0008-0x0018 : "u-boot" [2.379179] 0x0018-0x001c : "env1" [2.390627] 0x001c-0x0020 : "env2" [2.402255] 0x0020-0x2000 : "common_data" Reason is taht the mtd->name has changed from "omap2-nand.0" to the nand chip name ... If I revert this part from the patch diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c index 93f664c..28dcf66 100644 --- a/drivers/mtd/nand/omap2.c +++ b/drivers/mtd/nand/omap2.c @@ -1685,6 +1685,7 @@ static int omap_nand_probe(struct platform_device *pdev) info->ecc_opt = pdata->ecc_opt; mtd = >mtd; mtd->priv = >nand; + mtd->name = dev_name(>dev); mtd->dev.parent = >dev; nand_chip = >nand; nand_chip->ecc.priv = NULL; It works again ... So the question is, is it intended to change the "mtd->name"? But wondering, if there are two or more identical nand chips in the system, they will have the same mtd->name ... which seems buggy to me... bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] arm64: ftrace: fix the comments for ftrace_modify_code
I will also update the comment for the other arch that using the similar
description, such as ia64/metag/powerpc/sh/x86.
Thanks,
Li Bin
on 2015/12/4 10:50, Steven Rostedt wrote:
> On Fri, 4 Dec 2015 10:18:39 +0800
> Li Bin wrote:
>
>> There is no need to worry about module text disappearing case,
>> because that ftrace has a module notifier that is called when
>> a module is being unloaded and before the text goes away, and this
>> code grabs the ftrace_lock mutex and removes the module functions
>> from the ftrace list, such that it will no longer do any
>> modifications to that module's text.
>> The update to make functions be traced or not is done under the
>> ftrace_lock mutex as well.
>>
>> Signed-off-by: Li Bin
>> ---
>> arch/arm64/kernel/ftrace.c |5 +
>> 1 files changed, 1 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
>> index 9669b33..ee91c0c 100644
>> --- a/arch/arm64/kernel/ftrace.c
>> +++ b/arch/arm64/kernel/ftrace.c
>> @@ -29,12 +29,9 @@ static int ftrace_modify_code(unsigned long pc, u32 old,
>> u32 new,
>>
>> /*
>> * Note:
>> - * Due to modules and __init, code can disappear and change,
>> + * Due to __init, code can disappear and change,
> Init code should not be modified either because it is black listed in
> recordmcount.c.
>
> I say just change the comment to be something like:
>
> We are paranoid about modifying text, as if a bug were to happen, it
> could cause us to read or write to someplace that could cause harm.
> Carefully read and modify the code with aarch64_insn_*() which uses
> probe_kernel_*(), and make sure what we read is what we expected it to
> be before modifying it.
>
> -- Steve
>
>
>> * we need to protect against faulting as well as code changing.
>> * We do this by aarch64_insn_*() which use the probe_kernel_*().
>> - *
>> - * No lock is held here because all the modifications are run
>> - * through stop_machine().
>> */
>> if (validate) {
>> if (aarch64_insn_read((void *)pc, ))
>
> .
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] storvsc: add logging for error/warning messages
Introduce a logging level for storvsc to log certain error/warning messages.
Those messages are helpful in some environments, e.g. Microsoft Azure, for
customer support and troubleshooting purposes.
Signed-off-by: Long Li
---
drivers/scsi/storvsc_drv.c | 34 +-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 40c43ae..f46ed2c 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -164,6 +164,26 @@ static int sense_buffer_size =
PRE_WIN8_STORVSC_SENSE_BUFFER_SIZE;
*/
static int vmstor_proto_version;
+#define STORVSC_LOGGING_NONE 0
+#define STORVSC_LOGGING_ERROR 1
+#define STORVSC_LOGGING_WARN 2
+
+static int logging_level = STORVSC_LOGGING_ERROR;
+module_param(logging_level, int, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(logging_level,
+ "Logging level, 0 - None, 1 - Error (default), 2 - Warning.");
+
+static inline bool do_logging(int level)
+{
+ return logging_level >= level;
+}
+
+#define storvsc_log(dev, level, fmt, ...) \
+do { \
+ if (do_logging(level)) \
+ dev_warn(&(dev)->device, fmt, ##__VA_ARGS__); \
+} while (0)
+
struct vmscsi_win8_extension {
/*
* The following were added in Windows 8
@@ -1185,7 +1205,8 @@ static void storvsc_command_completion(struct
storvsc_cmd_request *cmd_request)
if (scmnd->result) {
if (scsi_normalize_sense(scmnd->sense_buffer,
- SCSI_SENSE_BUFFERSIZE, _hdr))
+ SCSI_SENSE_BUFFERSIZE, _hdr) &&
+ do_logging(STORVSC_LOGGING_ERROR))
scsi_print_sense_hdr(scmnd->device, "storvsc",
_hdr);
}
@@ -1239,6 +1260,13 @@ static void storvsc_on_io_completion(struct hv_device
*device,
stor_pkt->vm_srb.sense_info_length =
vstor_packet->vm_srb.sense_info_length;
+ if (vstor_packet->vm_srb.scsi_status != 0 ||
+ vstor_packet->vm_srb.srb_status != SRB_STATUS_SUCCESS)
+ storvsc_log(device, STORVSC_LOGGING_WARN,
+ "cmd 0x%x scsi status 0x%x srb status 0x%x\n",
+ stor_pkt->vm_srb.cdb[0],
+ vstor_packet->vm_srb.scsi_status,
+ vstor_packet->vm_srb.srb_status);
if ((vstor_packet->vm_srb.scsi_status & 0xFF) == 0x02) {
/* CHECK_CONDITION */
@@ -1246,6 +1274,10 @@ static void storvsc_on_io_completion(struct hv_device
*device,
SRB_STATUS_AUTOSENSE_VALID) {
/* autosense data available */
+ storvsc_log(device, STORVSC_LOGGING_WARN,
+ "stor pkt %p autosense data valid - len %d\n",
+ request,
vstor_packet->vm_srb.sense_info_length);
+
memcpy(request->cmd->sense_buffer,
vstor_packet->vm_srb.sense_data,
vstor_packet->vm_srb.sense_info_length);
--
1.8.5.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/3] reduce latency of direct async compaction
On Thu, Dec 03, 2015 at 09:10:44AM +0100, Vlastimil Babka wrote:
> Aaron, could you try this on your testcase?
One time result isn't stable enough, so I did 9 runs for each commit,
here is the result:
base: 25364a9e54fb8296837061bf684b76d20eec01fb
head: 7433b1009ff5a02e1e9f3444802daba2cf385d27
(head = base + this_patch_serie)
The always-always case(transparent_hugepage set to always and defrag set
to always):
Result for base:
$ cat {0..8}/swap
cmdline: /lkp/aaron/src/bin/usemem 10622592
10622592 transferred in 103 seconds, throughput: 925 MB/s
cmdline: /lkp/aaron/src/bin/usemem 9559680
9559680 transferred in 92 seconds, throughput: 1036 MB/s
cmdline: /lkp/aaron/src/bin/usemem 6171264
6171264 transferred in 92 seconds, throughput: 1036 MB/s
cmdline: /lkp/aaron/src/bin/usemem 15663744
15663744 transferred in 150 seconds, throughput: 635 MB/s
cmdline: /lkp/aaron/src/bin/usemem 12966528
12966528 transferred in 87 seconds, throughput: 1096 MB/s
cmdline: /lkp/aaron/src/bin/usemem 5784192
5784192 transferred in 131 seconds, throughput: 727 MB/s
cmdline: /lkp/aaron/src/bin/usemem 13731456
13731456 transferred in 97 seconds, throughput: 983 MB/s
cmdline: /lkp/aaron/src/bin/usemem 16440960
16440960 transferred in 109 seconds, throughput: 874 MB/s
cmdline: /lkp/aaron/src/bin/usemem 8813184
8813184 transferred in 122 seconds, throughput: 781 MB/s
Max: 1096 MB/s
Min: 635 MB/s
Avg: 899 MB/s
Result for head:
$ cat {0..8}/swap
cmdline: /lkp/aaron/src/bin/usemem 13163136
13163136 transferred in 105 seconds, throughput: 908 MB/s
cmdline: /lkp/aaron/src/bin/usemem 8524416
8524416 transferred in 78 seconds, throughput: 1222 MB/s
cmdline: /lkp/aaron/src/bin/usemem 3646080
3646080 transferred in 108 seconds, throughput: 882 MB/s
cmdline: /lkp/aaron/src/bin/usemem 8936064
8936064 transferred in 114 seconds, throughput: 836 MB/s
cmdline: /lkp/aaron/src/bin/usemem 12204672
12204672 transferred in 73 seconds, throughput: 1306 MB/s
cmdline: /lkp/aaron/src/bin/usemem 8140416
8140416 transferred in 146 seconds, throughput: 653 MB/s
cmdline: /lkp/aaron/src/bin/usemem 12941952
12941952 transferred in 78 seconds, throughput: 1222 MB/s
cmdline: /lkp/aaron/src/bin/usemem 6917760
6917760 transferred in 109 seconds, throughput: 874 MB/s
cmdline: /lkp/aaron/src/bin/usemem 11405952
11405952 transferred in 96 seconds, throughput: 993 MB/s
Max: 1306 MB/s
Min: 653 MB/s
Avg: 988 MB/s
Result for v4.3 as a reference:
$ cat {0..8}/swap
cmdline: /lkp/aaron/src/bin/usemem 12459648
12459648 transferred in 96 seconds, throughput: 993 MB/s
cmdline: /lkp/aaron/src/bin/usemem 7375488
7375488 transferred in 96 seconds, throughput: 993 MB/s
cmdline: /lkp/aaron/src/bin/usemem 9028224
9028224 transferred in 107 seconds, throughput: 891 MB/s
cmdline: /lkp/aaron/src/bin/usemem 10137216
10137216 transferred in 91 seconds, throughput: 1047 MB/s
cmdline: /lkp/aaron/src/bin/usemem 13835904
13835904 transferred in 80 seconds, throughput: 1192 MB/s
cmdline: /lkp/aaron/src/bin/usemem 10143360
10143360 transferred in 96 seconds, throughput: 993 MB/s
cmdline: /lkp/aaron/src/bin/usemem 100020593664
100020593664 transferred in 101 seconds, throughput: 944 MB/s
cmdline: /lkp/aaron/src/bin/usemem 15805056
15805056 transferred in 87 seconds, throughput: 1096 MB/s
cmdline: /lkp/aaron/src/bin/usemem 18360960
18360960 transferred in 74 seconds, throughput: 1288 MB/s
Max: 1288 MB/s
Min: 891 MB/s
Avg: 1048 MB/s
The always-never case:
Result for head:
$ cat {0..8}/swap
cmdline: /lkp/aaron/src/bin/usemem 13940352
13940352 transferred in 71 seconds, throughput: 1343 MB/s
cmdline: /lkp/aaron/src/bin/usemem 17411712
17411712 transferred in 62 seconds, throughput: 1538 MB/s
cmdline: /lkp/aaron/src/bin/usemem 11875968
11875968 transferred in 64 seconds, throughput: 1490 MB/s
cmdline: /lkp/aaron/src/bin/usemem 13912704
13912704 transferred in 62 seconds, throughput: 1538 MB/s
cmdline: /lkp/aaron/src/bin/usemem 12238464
12238464 transferred in 66 seconds, throughput: 1444 MB/s
cmdline: /lkp/aaron/src/bin/usemem 13670016
13670016 transferred in 65 seconds, throughput: 1467 MB/s
cmdline: /lkp/aaron/src/bin/usemem 8364672
8364672 transferred in 68 seconds, throughput: 1402 MB/s
cmdline: /lkp/aaron/src/bin/usemem 15417984
15417984 transferred in 70 seconds, throughput: 1362 MB/s
cmdline: /lkp/aaron/src/bin/usemem 15304320
15304320 transferred in 64 seconds, throughput: 1490 MB/s
Max: 1538 MB/s
Min: 1343 MB/s
Avg: 1452 MB/s
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [lustre cleanups 0/6] Patch series to make lustre safe(r) for W=1 compiles
On 2015/12/01, 15:05, "Valdis Kletnieks" wrote: >Start of a batch series to clean up the Lustre tree. Other people have >done some sparse and checkpatch cleanups, but I found a bunch of >stuff building with W=1. Hello Valdis, thanks for these patches. Strictly speaking, they should also be sent to "Greg Kroah-Hartman " and also de...@driverdev.osuosl.org because Lustre is still in the staging tree. Also, for the patch subject line, it is standard to use something like: [PATCH 1/6] staging/lustre: Swap inline/const to kill 272 warnings as generated by "git format-patch". Could you please resubmit your patch series so that Greg sees your patches. Cheers, Andreas >Valdis Kletnieks (6): > > Swap inline/const to kill 272 warnings > Fix set-but-unused whinge. > Clean up another C warnining: > Fix another C compiler whine: > Nuke an unsigned >= 0 assert > Nuke another unsigned >= 0 assert > > drivers/staging/lustre/lustre/fid/lproc_fid.c | 1 + > drivers/staging/lustre/lustre/include/lu_object.h | 2 +- > drivers/staging/lustre/lustre/include/lustre_cfg.h | 4 -- > drivers/staging/lustre/lustre/libcfs/module.c | 15 > drivers/staging/lustre/lustre/llite/rw.c | 1 - > drivers/staging/lustre/lustre/ptlrpc/sec_bulk.c| 1 - > 7 files changed, 26 insertions(+), 41 deletions(-) > >-- >2.6.3 > > Cheers, Andreas -- Andreas Dilger Lustre Principal Architect Intel High Performance Data Division -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] thermal: rcar: enable to use thermal-zone on DT
Hi
> +static int rcar_thermal_of_get_temp(void *data, int *temp)
> +{
> + struct rcar_thermal_priv *priv = data;
> +
> + *temp = rcar_thermal_get_current_temp(priv);
> +
> + return 0;
> +}
> +
> +static int rcar_thermal_get_temp(struct thermal_zone_device *zone, int *temp)
> +{
> + struct rcar_thermal_priv *priv = rcar_zone_to_priv(zone);
> +
> + *temp = rcar_thermal_get_current_temp(priv);
> +
> return 0;
> }
>
Above two function, always returns 0. Can it possible to handle error
and log some messages.
Regards
Manish Badarkhe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 5/6] cpufreq: governor: replace per-cpu delayed work with timers
cpufreq governors evaluate load at sampling rate and based on that they
update frequency for a group of CPUs belonging to the same cpufreq
policy.
This is required to be done in a single thread for all policy->cpus, but
because we don't want to wakeup idle CPUs to do just that, we use
deferrable work for this. If we would have used a single delayed
deferrable work for the entire policy, there were chances that the CPU
required to run the handler can be in idle and we might end up not
changing the frequency for the entire group with load variations.
And so we were forced to keep per-cpu works, and only the one that
expires first need to do the real work and others are rescheduled for
next sampling time.
We have been using the more complex solution until now, where we used a
delayed deferrable work for this, which is a combination of a timer and
a work.
This could be made lightweight by keeping per-cpu deferred timers with a
single work item, which is scheduled by the first timer that expires.
This patch does just that and here are important changes:
- The timer handler will run in irq context and so we need to use a
spin_lock instead of the timer_mutex. And so a separate timer_lock is
created. This also makes the use of the mutex and lock quite clear, as
we know what exactly they are protecting.
- A new field 'skip_work' is added to track when the timer handlers can
queue a work. More comments present in code.
Suggested-by: Rafael J. Wysocki
Signed-off-by: Viresh Kumar
Reviewed-by: Ashwin Chaugule
---
V2->V3:
- Dropped unused variable policy
- Rearranged code to kill an extra label
drivers/cpufreq/cpufreq_governor.c | 137 +
drivers/cpufreq/cpufreq_governor.h | 20 --
drivers/cpufreq/cpufreq_ondemand.c | 8 +--
3 files changed, 95 insertions(+), 70 deletions(-)
diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq_governor.c
index 999e1f6addf9..c9e420bd0eec 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -158,47 +158,52 @@ void dbs_check_cpu(struct dbs_data *dbs_data, int cpu)
}
EXPORT_SYMBOL_GPL(dbs_check_cpu);
-static inline void __gov_queue_work(int cpu, struct dbs_data *dbs_data,
- unsigned int delay)
+void gov_add_timers(struct cpufreq_policy *policy, unsigned int delay)
{
- struct cpu_dbs_info *cdbs = dbs_data->cdata->get_cpu_cdbs(cpu);
-
- mod_delayed_work_on(cpu, system_wq, >dwork, delay);
-}
-
-void gov_queue_work(struct dbs_data *dbs_data, struct cpufreq_policy *policy,
- unsigned int delay, bool all_cpus)
-{
- int i;
+ struct dbs_data *dbs_data = policy->governor_data;
+ struct cpu_dbs_info *cdbs;
+ int cpu;
- if (!all_cpus) {
- /*
-* Use raw_smp_processor_id() to avoid preemptible warnings.
-* We know that this is only called with all_cpus == false from
-* works that have been queued with *_work_on() functions and
-* those works are canceled during CPU_DOWN_PREPARE so they
-* can't possibly run on any other CPU.
-*/
- __gov_queue_work(raw_smp_processor_id(), dbs_data, delay);
- } else {
- for_each_cpu(i, policy->cpus)
- __gov_queue_work(i, dbs_data, delay);
+ for_each_cpu(cpu, policy->cpus) {
+ cdbs = dbs_data->cdata->get_cpu_cdbs(cpu);
+ cdbs->timer.expires = jiffies + delay;
+ add_timer_on(>timer, cpu);
}
}
-EXPORT_SYMBOL_GPL(gov_queue_work);
+EXPORT_SYMBOL_GPL(gov_add_timers);
-static inline void gov_cancel_work(struct dbs_data *dbs_data,
- struct cpufreq_policy *policy)
+static inline void gov_cancel_timers(struct cpufreq_policy *policy)
{
+ struct dbs_data *dbs_data = policy->governor_data;
struct cpu_dbs_info *cdbs;
int i;
for_each_cpu(i, policy->cpus) {
cdbs = dbs_data->cdata->get_cpu_cdbs(i);
- cancel_delayed_work_sync(>dwork);
+ del_timer_sync(>timer);
}
}
+void gov_cancel_work(struct cpu_common_dbs_info *shared)
+{
+ unsigned long flags;
+
+ /*
+* No work will be queued from timer handlers after skip_work is
+* updated. And so we can safely cancel the work first and then the
+* timers.
+*/
+ spin_lock_irqsave(>timer_lock, flags);
+ shared->skip_work++;
+ spin_unlock_irqrestore(>timer_lock, flags);
+
+ cancel_work_sync(>work);
+
+ gov_cancel_timers(shared->policy);
+
+ shared->skip_work = 0;
+}
+
/* Will return if we need to evaluate cpu load again or not */
static bool need_load_eval(struct cpu_common_dbs_info *shared,
unsigned int sampling_rate)
@@ -217,29 +222,21 @@ static bool need_load_eval(struct cpu_common_dbs_info
*shared,
return true;
}
Re: [PATCH V2 5/6] cpufreq: governor: replace per-cpu delayed work with timers
On 04-12-15, 02:18, Rafael J. Wysocki wrote:
> > + shared->skip_work--;
>
> Is there any reason for incrementing and decrementing this instead of setting
> it to either 0 or 1 (or maybe either 'true' or 'false' for that matter)?
>
> If my reading of the patch is correct, it can only be either 0 or 1 anyway,
> right?
No. It can be 0, 1 or 2.
If the timer handler is running on any CPU, we increment skip_work, so
its value is 1. If at the same time, we try to stop the governor, we
increment it again and its value is 2 now.
Once timer-handler finishes, it decrements it and its value become 1.
Which guarantees that no other timer handler starts executing at this
point of time and we can safely do gov_cancel_timers(). And once we
are sure that we don't have any work/timer left, we make it 0 (as we
aren't sure of the current value, which can be 0 (if the timer handler
wasn't running when we stopped the governor) or 1 (if the timer
handler was running while stopping the governor)).
Hope this clarifies it.
> > +static void dbs_timer_handler(unsigned long data)
> > +{
> > + struct cpu_dbs_info *cdbs = (struct cpu_dbs_info *)data;
> > + struct cpu_common_dbs_info *shared = cdbs->shared;
> > + struct cpufreq_policy *policy;
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(>timer_lock, flags);
> > + policy = shared->policy;
>
> Why do we need policy here?
>
> > +
> > + /*
> > +* Timer handler isn't allowed to queue work at the moment, because:
> > +* - Another timer handler has done that
> > +* - We are stopping the governor
> > +* - Or we are updating the sampling rate of ondemand governor
> > +*/
> > + if (shared->skip_work)
> > + goto unlock;
> > +
> > + shared->skip_work++;
> > + queue_work(system_wq, >work);
> >
> > unlock:
>
> What about writing the above as
>
> if (!shared->work_in_progress) {
> shared->work_in_progress = true;
> queue_work(system_wq, >work);
> }
>
> and then you won't need the unlock label.
Here is a diff for that:
diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq_governor.c
index a3f9bc9b98e9..c9e420bd0eec 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -265,11 +265,9 @@ static void dbs_timer_handler(unsigned long data)
{
struct cpu_dbs_info *cdbs = (struct cpu_dbs_info *)data;
struct cpu_common_dbs_info *shared = cdbs->shared;
- struct cpufreq_policy *policy;
unsigned long flags;
spin_lock_irqsave(>timer_lock, flags);
- policy = shared->policy;
/*
* Timer handler isn't allowed to queue work at the moment, because:
@@ -277,13 +275,11 @@ static void dbs_timer_handler(unsigned long data)
* - We are stopping the governor
* - Or we are updating the sampling rate of ondemand governor
*/
- if (shared->skip_work)
- goto unlock;
-
- shared->skip_work++;
- queue_work(system_wq, >work);
+ if (!shared->skip_work) {
+ shared->skip_work++;
+ queue_work(system_wq, >work);
+ }
-unlock:
spin_unlock_irqrestore(>timer_lock, flags);
}
I will resend this patch now.
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] clocksource: h8300: Change to overflow interrupt
Counter overflow detection use for overflow interrupt
Signed-off-by: Yoshinori Sato
---
drivers/clocksource/h8300_timer16.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/clocksource/h8300_timer16.c
b/drivers/clocksource/h8300_timer16.c
index fc14a3f..b14a8da 100644
--- a/drivers/clocksource/h8300_timer16.c
+++ b/drivers/clocksource/h8300_timer16.c
@@ -14,7 +14,6 @@
#include
#define TSTR 0
-#define TISRA 4
#define TISRC 6
#define TCR0
@@ -27,9 +26,8 @@ struct timer16_priv {
void __iomem *mapcommon;
unsigned short cs_enabled;
unsigned char enb;
- unsigned char imfa;
- unsigned char imiea;
unsigned char ovf;
+ unsigned char ovie;
struct clk *clk;
};
@@ -59,8 +57,8 @@ static irqreturn_t timer16_interrupt(int irq, void *dev_id)
{
struct timer16_priv *p = (struct timer16_priv *)dev_id;
- writeb(readb(p->mapcommon + TISRA) & ~p->imfa,
- p->mapcommon + TISRA);
+ writeb(readb(p->mapcommon + TISRC) & ~p->ovf,
+ p->mapcommon + TISRC);
p->total_cycles += 0x1;
return IRQ_HANDLED;
@@ -93,6 +91,8 @@ static int timer16_enable(struct clocksource *cs)
writeb(0x83, p->mapbase + TCR);
writeb(readb(p->mapcommon + TSTR) | p->enb,
p->mapcommon + TSTR);
+ writeb(readb(p->mapcommon + TISRC) | p->ovie,
+ p->mapcommon + TSTR);
p->cs_enabled = true;
return 0;
@@ -161,8 +161,8 @@ static void __init h8300_16timer_init(struct device_node
*node)
timer16_priv.mapbase = base[REG_CH];
timer16_priv.mapcommon = base[REG_COMM];
timer16_priv.enb = 1 << ch;
- timer16_priv.imfa = 1 << ch;
- timer16_priv.imiea = 1 << (4 + ch);
+ timer16_priv.ovf = 1 << ch;
+ timer16_priv.ovie = 1 << (4 + ch);
ret = request_irq(irq, timer16_interrupt,
IRQF_TIMER, timer16_priv.cs.name, _priv);
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] clocksource: h8300: Fix timer not overflow case
Signed-off-by: Yoshinori Sato --- drivers/clocksource/h8300_timer16.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/clocksource/h8300_timer16.c b/drivers/clocksource/h8300_timer16.c index b14a8da..934ed0b 100644 --- a/drivers/clocksource/h8300_timer16.c +++ b/drivers/clocksource/h8300_timer16.c @@ -48,8 +48,10 @@ static unsigned long timer16_get_counter(struct timer16_priv *p) } while (unlikely((o1 != o2) || (v1 > v2 && v1 < v3) || (v2 > v3 && v2 < v1) || (v3 > v1 && v3 < v2))); - v2 |= 0x1; - return v2; + if (likely(!o1)) + return v2; + else + return v2 + 0x1; } -- 2.6.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] clocksource: h8300: Simplify delta handling
Signed-off-by: Yoshinori Sato
---
drivers/clocksource/h8300_timer8.c | 40 ++
1 file changed, 6 insertions(+), 34 deletions(-)
diff --git a/drivers/clocksource/h8300_timer8.c
b/drivers/clocksource/h8300_timer8.c
index aa4b2a98..1ba453b 100644
--- a/drivers/clocksource/h8300_timer8.c
+++ b/drivers/clocksource/h8300_timer8.c
@@ -36,57 +36,29 @@ struct timer8_priv {
unsigned int tcora;
};
-static unsigned long timer8_get_counter(struct timer8_priv *p)
-{
- unsigned long v1, v2, v3;
- int o1, o2;
-
- o1 = readb(p->mapbase + _8TCSR) & 0x20;
-
- /* Make sure the timer value is stable. Stolen from acpi_pm.c */
- do {
- o2 = o1;
- v1 = readw(p->mapbase + _8TCNT);
- v2 = readw(p->mapbase + _8TCNT);
- v3 = readw(p->mapbase + _8TCNT);
- o1 = readb(p->mapbase + _8TCSR) & 0x20;
- } while (unlikely((o1 != o2) || (v1 > v2 && v1 < v3)
- || (v2 > v3 && v2 < v1) || (v3 > v1 && v3 < v2)));
-
- v2 |= o1 << 10;
- return v2;
-}
-
static irqreturn_t timer8_interrupt(int irq, void *dev_id)
{
struct timer8_priv *p = dev_id;
- writeb(readb(p->mapbase + _8TCSR) & ~0x40,
- p->mapbase + _8TCSR);
-
- writew(p->tcora, p->mapbase + TCORA);
-
if (clockevent_state_oneshot(>ced))
writew(0x, p->mapbase + _8TCR);
p->ced.event_handler(>ced);
+ writeb(readb(p->mapbase + _8TCSR) & ~0x40,
+ p->mapbase + _8TCSR);
+
return IRQ_HANDLED;
}
static void timer8_set_next(struct timer8_priv *p, unsigned long delta)
{
- unsigned long now;
-
if (delta >= 0x1)
pr_warn("delta out of range\n");
- now = timer8_get_counter(p);
- p->tcora = delta;
+ writeb(readb(p->mapbase + _8TCR) & ~0x40, p->mapbase + _8TCR);
+ writew(0, p->mapbase + _8TCNT);
+ writew(delta, p->mapbase + TCORA);
writeb(readb(p->mapbase + _8TCR) | 0x40, p->mapbase + _8TCR);
- if (delta > now)
- writew(delta, p->mapbase + TCORA);
- else
- writew(now + 1, p->mapbase + TCORA);
}
static int timer8_enable(struct timer8_priv *p)
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] clocksource: h8300: Use ioread / iowrite
Signed-off-by: Yoshinori Sato
---
drivers/clocksource/h8300_timer16.c | 40 +
drivers/clocksource/h8300_timer8.c | 25 +--
drivers/clocksource/h8300_tpu.c | 22 ++--
3 files changed, 44 insertions(+), 43 deletions(-)
diff --git a/drivers/clocksource/h8300_timer16.c
b/drivers/clocksource/h8300_timer16.c
index 934ed0b..e8a7d0f 100644
--- a/drivers/clocksource/h8300_timer16.c
+++ b/drivers/clocksource/h8300_timer16.c
@@ -28,23 +28,22 @@ struct timer16_priv {
unsigned char enb;
unsigned char ovf;
unsigned char ovie;
- struct clk *clk;
};
static unsigned long timer16_get_counter(struct timer16_priv *p)
{
- unsigned long v1, v2, v3;
- int o1, o2;
+ unsigned short v1, v2, v3;
+ unsigned char o1, o2;
- o1 = readb(p->mapcommon + TISRC) & p->ovf;
+ o1 = ioread8(p->mapcommon + TISRC) & p->ovf;
/* Make sure the timer value is stable. Stolen from acpi_pm.c */
do {
o2 = o1;
- v1 = readw(p->mapbase + TCNT);
- v2 = readw(p->mapbase + TCNT);
- v3 = readw(p->mapbase + TCNT);
- o1 = readb(p->mapcommon + TISRC) & p->ovf;
+ v1 = ioread16be(p->mapbase + TCNT);
+ v2 = ioread16be(p->mapbase + TCNT);
+ v3 = ioread16be(p->mapbase + TCNT);
+ o1 = ioread8(p->mapcommon + TISRC) & p->ovf;
} while (unlikely((o1 != o2) || (v1 > v2 && v1 < v3)
|| (v2 > v3 && v2 < v1) || (v3 > v1 && v3 < v2)));
@@ -59,8 +58,7 @@ static irqreturn_t timer16_interrupt(int irq, void *dev_id)
{
struct timer16_priv *p = (struct timer16_priv *)dev_id;
- writeb(readb(p->mapcommon + TISRC) & ~p->ovf,
- p->mapcommon + TISRC);
+ ctrl_bclr(p->ovf, p->mapcommon + TISRC);
p->total_cycles += 0x1;
return IRQ_HANDLED;
@@ -89,12 +87,10 @@ static int timer16_enable(struct clocksource *cs)
WARN_ON(p->cs_enabled);
p->total_cycles = 0;
- writew(0x, p->mapbase + TCNT);
- writeb(0x83, p->mapbase + TCR);
- writeb(readb(p->mapcommon + TSTR) | p->enb,
- p->mapcommon + TSTR);
- writeb(readb(p->mapcommon + TISRC) | p->ovie,
- p->mapcommon + TSTR);
+ iowrite16be(0x, p->mapbase + TCNT);
+ iowrite8(0x83, p->mapbase + TCR);
+ ctrl_bset(p->ovie, p->mapcommon + TISRC);
+ ctrl_bset(p->enb, p->mapcommon + TSTR);
p->cs_enabled = true;
return 0;
@@ -106,8 +102,8 @@ static void timer16_disable(struct clocksource *cs)
WARN_ON(!p->cs_enabled);
- writeb(readb(p->mapcommon + TSTR) & ~p->enb,
- p->mapcommon + TSTR);
+ ctrl_bclr(p->ovie, p->mapcommon + TISRC);
+ ctrl_bclr(p->enb, p->mapcommon + TSTR);
p->cs_enabled = false;
}
@@ -162,9 +158,9 @@ static void __init h8300_16timer_init(struct device_node
*node)
timer16_priv.mapbase = base[REG_CH];
timer16_priv.mapcommon = base[REG_COMM];
- timer16_priv.enb = 1 << ch;
- timer16_priv.ovf = 1 << ch;
- timer16_priv.ovie = 1 << (4 + ch);
+ timer16_priv.enb = ch;
+ timer16_priv.ovf = ch;
+ timer16_priv.ovie = 4 + ch;
ret = request_irq(irq, timer16_interrupt,
IRQF_TIMER, timer16_priv.cs.name, _priv);
@@ -174,7 +170,7 @@ static void __init h8300_16timer_init(struct device_node
*node)
}
clocksource_register_hz(_priv.cs,
- clk_get_rate(timer16_priv.clk) / 8);
+ clk_get_rate(clk) / 8);
return;
unmap_comm:
diff --git a/drivers/clocksource/h8300_timer8.c
b/drivers/clocksource/h8300_timer8.c
index 9087dd2..2279522 100644
--- a/drivers/clocksource/h8300_timer8.c
+++ b/drivers/clocksource/h8300_timer8.c
@@ -24,6 +24,9 @@
#define TCORB 6
#define _8TCNT 8
+#define CMIEA 6
+#define CMFA 6
+
#define FLAG_STARTED (1 << 3)
#define SCALE 64
@@ -40,12 +43,11 @@ static irqreturn_t timer8_interrupt(int irq, void *dev_id)
struct timer8_priv *p = dev_id;
if (clockevent_state_oneshot(>ced))
- writew(0x, p->mapbase + _8TCR);
+ iowrite16be(0x, p->mapbase + _8TCR);
p->ced.event_handler(>ced);
- writeb(readb(p->mapbase + _8TCSR) & ~0x40,
- p->mapbase + _8TCSR);
+ ctrl_bclr(CMFA, p->mapbase + _8TCSR);
return IRQ_HANDLED;
}
@@ -54,17 +56,18 @@ static void timer8_set_next(struct timer8_priv *p, unsigned
long delta)
{
if (delta >= 0x1)
pr_warn("delta out of range\n");
- writeb(readb(p->mapbase + _8TCR) & ~0x40, p->mapbase + _8TCR);
- writew(0, p->mapbase + _8TCNT);
- writew(delta, p->mapbase + TCORA);
- writeb(readb(p->mapbase + _8TCR) | 0x40, p->mapbase + _8TCR);
+
[PATCH 4/5] clocksource: h8300: Initializer cleanup.
Signed-off-by: Yoshinori Sato
---
drivers/clocksource/h8300_timer8.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/clocksource/h8300_timer8.c
b/drivers/clocksource/h8300_timer8.c
index 1ba453b..9087dd2 100644
--- a/drivers/clocksource/h8300_timer8.c
+++ b/drivers/clocksource/h8300_timer8.c
@@ -33,7 +33,6 @@ struct timer8_priv {
void __iomem *mapbase;
unsigned long flags;
unsigned int rate;
- unsigned int tcora;
};
static irqreturn_t timer8_interrupt(int irq, void *dev_id)
@@ -163,8 +162,6 @@ static void __init h8300_8timer_init(struct device_node
*node)
{
void __iomem *base;
int irq;
- int ret = 0;
- int rate;
struct clk *clk;
clk = of_clk_get(node, 0);
@@ -187,20 +184,20 @@ static void __init h8300_8timer_init(struct device_node
*node)
timer8_priv.mapbase = base;
- rate = clk_get_rate(clk) / SCALE;
- if (!rate) {
+ timer8_priv.rate = clk_get_rate(clk) / SCALE;
+ if (!timer8_priv.rate) {
pr_err("Failed to get rate for the clocksource\n");
goto unmap_reg;
}
- ret = request_irq(irq, timer8_interrupt,
- IRQF_TIMER, timer8_priv.ced.name, _priv);
- if (ret < 0) {
+ if (request_irq(irq, timer8_interrupt, IRQF_TIMER,
+ timer8_priv.ced.name, _priv) < 0) {
pr_err("failed to request irq %d for clockevent\n", irq);
goto unmap_reg;
}
- clockevents_config_and_register(_priv.ced, rate, 1, 0x);
+ clockevents_config_and_register(_priv.ced,
+ timer8_priv.rate, 1, 0x);
return;
unmap_reg:
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] clocksource: h8300: driver update
Hi Daniel, Thomas, Update h8300 clocksource / clockevents driver Changes bellow h8300_timer8.c: Cleanup set_next_event handler. Use ioread / iowrite functions. h8300_timer16.c: Overflow handling fix. Use ioread / iowrite functions. h8300_tpu.c: Use ioread / iowrite functions. Thanks. Yoshinori Sato (5): clocksource: h8300: Change to overflow interrupt clocksource: h8300: Fix timer not overflow case clocksource: h8300: Simplify delta handling clocksource: h8300: Initializer cleanup. clocksource: h8300: Use ioread / iowrite drivers/clocksource/h8300_timer16.c | 48 - drivers/clocksource/h8300_timer8.c | 70 +++-- drivers/clocksource/h8300_tpu.c | 22 ++-- 3 files changed, 56 insertions(+), 84 deletions(-) -- 2.6.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Hang triggered by udev coldplug, looks like a race
Sometimes udevadm trigger --action=add hangs the system, and the splat below happens. This seems to be timing dependent, and I haven't been able to trigger it yet with lockdep enabled, sadly. Any ideas? I not, I'll try to instrument it better tomorrow. This is 4.4-rc3 plus some patches that I don't think are related. The rootfs is 9p. --Andy [ 60.048359] INFO: task kworker/u2:1:980 blocked for more than 30 seconds. [ 60.051673] Not tainted 4.3.0-rc4+ #3 [ 60.052149] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 60.053013] kworker/u2:1D 880006823bc8 14152 980 14 0x [ 60.053786] 880006823bc8 8800072e4740 8800072e63c0 880006824000 [ 60.054637] 88000613cfd0 8800072e63c0 0246 [ 60.055447] 880006823be0 818d2bfe 88000613cfc8 880006823bf0 [ 60.056250] Call Trace: [ 60.056513] [] schedule+0x2e/0x70 [ 60.057017] [] schedule_preempt_disabled+0x9/0x10 [ 60.057632] [] __mutex_lock_slowpath+0x107/0x2f0 [ 60.058242] [] ? lookup_fast+0x133/0x2e0 [ 60.058790] [] mutex_lock+0x15/0x30 [ 60.059272] [] path_openat+0x63f/0x1220 [ 60.059805] [] do_filp_open+0x79/0xd0 [ 60.060352] [] ? selinux_cred_prepare+0x16/0x30 [ 60.060966] [] ? security_prepare_creds+0x3e/0x60 [ 60.061805] [] do_open_execat+0x5f/0x150 [ 60.062316] [] do_execveat_common.isra.33+0x1a3/0x6c0 [ 60.062916] [] do_execve+0x27/0x30 [ 60.063355] [] call_usermodehelper_exec_async+0xeb/0x140 [ 60.063951] [] ret_from_fork+0x22/0x40 [ 60.064416] [] ? umh_complete+0x40/0x40 [ 60.064889] INFO: task kworker/u2:1:981 blocked for more than 30 seconds. [ 60.065473] Not tainted 4.3.0-rc4+ #3 [ 60.065834] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 60.066507] kworker/u2:1D 880006827bc8 14152 981 14 0x [ 60.067135] 880006827bc8 880006965580 8800072e0e40 880006828000 [ 60.067810] 88000613cfd0 8800072e0e40 0246 [ 60.068491] 880006827be0 818d2bfe 88000613cfc8 880006827bf0 [ 60.069169] Call Trace: [ 60.069386] [] schedule+0x2e/0x70 [ 60.069814] [] schedule_preempt_disabled+0x9/0x10 [ 60.070361] [] __mutex_lock_slowpath+0x107/0x2f0 [ 60.070898] [] ? lookup_fast+0x133/0x2e0 [ 60.071381] [] mutex_lock+0x15/0x30 [ 60.071825] [] path_openat+0x63f/0x1220 [ 60.072299] [] do_filp_open+0x79/0xd0 [ 60.072756] [] ? selinux_cred_prepare+0x16/0x30 [ 60.073289] [] ? security_prepare_creds+0x3e/0x60 [ 60.073832] [] do_open_execat+0x5f/0x150 [ 60.074316] [] do_execveat_common.isra.33+0x1a3/0x6c0 [ 60.075083] [] do_execve+0x27/0x30 [ 60.075736] [] call_usermodehelper_exec_async+0xeb/0x140 [ 60.076648] [] ret_from_fork+0x22/0x40 [ 60.077235] [] ? umh_complete+0x40/0x40 [ 60.077805] INFO: task kworker/u2:1:982 blocked for more than 30 seconds. [ 60.078529] Not tainted 4.3.0-rc4+ #3 [ 60.078969] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 60.079891] kworker/u2:1D 88000682bbc8 14584 982 14 0x [ 60.080658] 88000682bbc8 8800064cb900 880006bc0e40 88000682c000 [ 60.081474] 88000613cfd0 880006bc0e40 0246 [ 60.082282] 88000682bbe0 818d2bfe 88000613cfc8 88000682bbf0 [ 60.083095] Call Trace: [ 60.083357] [] schedule+0x2e/0x70 [ 60.083871] [] schedule_preempt_disabled+0x9/0x10 [ 60.084533] [] __mutex_lock_slowpath+0x107/0x2f0 [ 60.085181] [] ? lookup_fast+0x133/0x2e0 [ 60.085761] [] mutex_lock+0x15/0x30 [ 60.086300] [] path_openat+0x63f/0x1220 [ 60.086869] [] do_filp_open+0x79/0xd0 [ 60.087422] [] ? selinux_cred_prepare+0x16/0x30 [ 60.088067] [] ? security_prepare_creds+0x3e/0x60 [ 60.088722] [] do_open_execat+0x5f/0x150 [ 60.089301] [] do_execveat_common.isra.33+0x1a3/0x6c0 [ 60.089991] [] do_execve+0x27/0x30 [ 60.090552] [] call_usermodehelper_exec_async+0xeb/0x140 [ 60.091274] [] ret_from_fork+0x22/0x40 [ 60.091832] [] ? umh_complete+0x40/0x40 [ 60.092401] INFO: task kworker/u2:1:983 blocked for more than 30 seconds. [ 60.093138] Not tainted 4.3.0-rc4+ #3 [ 60.093574] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 60.094379] kworker/u2:1D 88000682fbc8 14544 983 14 0x [ 60.095139] 88000682fbc8 880006bc0e40 88000644c740 88000683 [ 60.095973] 88000613cfd0 88000644c740 0246 [ 60.096871] 88000682fbe0 818d2bfe 88000613cfc8 88000682fbf0 [ 60.097686] Call Trace: [ 60.097945] [] schedule+0x2e/0x70 [ 60.098472] [] schedule_preempt_disabled+0x9/0x10 [ 60.099136] [] __mutex_lock_slowpath+0x107/0x2f0 [ 60.099786] [] ? lookup_fast+0x133/0x2e0 [ 60.100368] []
Re: [Question] DT-Bindings for run-time configurable bus?
Hi Arnd,
2015-12-01 20:29 GMT+09:00 Arnd Bergmann :
> On Tuesday 01 December 2015 13:30:25 Masahiro Yamada wrote:
>> Hello experts,
>>
>> I am tackling on a new bus driver, but I am worndering
>> what the DT-binding specification should be.
>>
>> Here is my hardware situation:
>>
>> My SoC has an external bus (it is called UniPhier System Bus).
>> This is a simple parallel bus with address, data,
>> chip-selects, and some other control signals.
>> It supports up to 8 chip-selects.
>>
>> Each CS address space can be mapped onto the CPU view,
>> and it must be configured run-time via the bus controller registers.
>>
>> Let's assume this situation:
>>
>> - An ethernet device is connected at the offset address 0x01f0 of CS1
>> - A UART device is connected at the offset address 0x0020 of CS5
>>
>>
>> A quick draft of device tree would be as follows:
>>
>>
>> amba {
>> compatible = "simple-bus";
>> #address-cells = <1>;
>> #size-cells = <1>;
>> ranges;
>>
>> extbus {
>>compatible = "socionext,uniphier-system-bus";
>>reg = <0x58c0 0x400>; /* registers of bus controller */
>>#address-cells = <2>;
>>#size-cells = <1>;
>>
>>ethernet@1,01f0 {
>> compatible = "smsc,lan9115";
>> reg = <1 0x01f0 0x1000>;
>> interrupts = <0 48 4>
>> phy-mode = "mii";
>>};
>>
>>uart@5,0020 {
>> compatible = "ns16550a";
>> reg = <5 0x0020 0x20>;
>> interrupts = <0 49 4>
>> clock-frequency = <12288000>;
>>};
>> };
>> };
>>
>
> That looks reasonable.
>
>> Please note "ranges" property is missing from the extbus node.
>>
>> As mentioned above, the address translation from the external bus
>> to the parent bus is run-time configurable.
>>
>>
>> It is possible to map
>> CS1 of extbus to 0x4000-0x41ff of CPU view
>> CS5 of extbus to 0x4200-0x43ff of CPU view
>>
>> It is also possible to map
>> CS1 of extbus to 0x4600-0x47ff of CPU view
>> CS5 of extbus to 0x4400-0x45ff of CPU view
>>
>> There is nothing preventing us from a particular
>> address mapping.
>> It is completely up to the software (driver)
>> to choose one mapping from another.
>
> Ok.
>
>> And I notice a conflict between the followings.
>>
>> [1] Device Tree is a hardware description language.
>> It should not describe the software configuration.
>>
>> So, ranges such as
>>ranges = <1 0 0x4000 0x0200
>> 5 0 0x4200 0x0200>;
>>
>>or
>>
>>ranges = <1 0 0x4600 0x0200
>> 5 0 0x4400 0x0200>;
>>
>> are configuration information, which should not be
>> included in the device tree.
>>
>> Any address mapping is OK as long as no region overlap occurs.
>> No point to specify "ranges" from the device tree.
>>
>>
>> [2] of_translate_address() expects "ranges" in every bus node
>>
>> When we need to translate the "reg" property into the CPU-viewed address,
>> we call of_translate_address(). It translates addresses,
>> parsing "ranges" property when crossing buses.
>> It potentially means, "ranges" properties are statically defined
>> in the device tree.
>>
>>
>> I have not been able to find a good way
>> to solve the conflict between [1] and [2].
>>
>>
>> To sum up, what I want is:
>>
>> - Let the driver to configure the address translation on run-time
>> - Once the bus is configured, I want the sub nodes to be accessed
>>from the CPU, like the other statically instantiated devices.
>>
>>
>> Any comment is welcome!
>>
>>
>> BTW, perhaps Marvell Mbus has a similar situation (run-time configurable)?
>> (Documentation/devicetree/bindings/bus/mvebu-mbus.txt)
>> I am not familiar with such SoCs, though.
>
> Yes, this is the example I was thinking of. For mbus, we decided that
> doing the full dynamic reassignment of addresses is too bothersome
> for the OS, so the DT contains a "reasonable" default that the OS can
> use. This is also what we do for most PCI host controllers on embedded
> systems. They tend to have programmable translations, and the DT contains
> the settings that are known to work and that the driver uses to set up
> the I/O windows even if a lot of other settings would work just as
> well.
>
> A more traditional setup that we use on server-class machines is that
> the bootloader decides what the windows should be, sets them up and
> documents them in DT. The OS can still change them if it wants to,
> but it doesn't actually have to worry about the fact that those are
> programmable, or what registers are used for programming them.
>
Thanks,
I managed to submit v2.
--
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[PATCH v2] bus: uniphier-system-bus: add UniPhier System Bus driver
The UniPhier System Bus is a simple external that connects on-board
devices to the UniPhier SoC. Each bank (chip select) is dynamically
mapped to the CPU-viewed address base via the bus controller. The
bus controller must be configured before any access to the bus.
This driver parses the "ranges" property of the System Bus node and
initialized the bus controller. After the bus becomes ready, devices
below it are populated.
Note:
Each bank can be mapped anywhere in the supported address space;
there is nothing preventing us from assigning bank 0 on 0x4200,
0x4300, or anywhere as long as such region is not used by others.
So, the "ranges" is just one possible software configuration, which
does not seem to fit in device tree because device tree is a hardware
description language. However, of_translate_address() requires
"ranges" in every bus node between CPUs and device mapped on the CPU
address space. In other words, "ranges" properties must be statically
defined in device tree. After some discussion, I decided the self
address reassignment by the driver is too bothersome. Instead, the
device tree should provide a reasonable translation setup that the OS
can rely on.
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Re-design the binding, driver implementation
Switch to a single node, populate children after the bus is setup
.../bindings/bus/uniphier-system-bus.txt | 65 +
MAINTAINERS| 1 +
drivers/bus/Kconfig| 8 +
drivers/bus/Makefile | 1 +
drivers/bus/uniphier-system-bus.c | 283 +
5 files changed, 358 insertions(+)
create mode 100644
Documentation/devicetree/bindings/bus/uniphier-system-bus.txt
create mode 100644 drivers/bus/uniphier-system-bus.c
diff --git a/Documentation/devicetree/bindings/bus/uniphier-system-bus.txt
b/Documentation/devicetree/bindings/bus/uniphier-system-bus.txt
new file mode 100644
index 000..5ec47c0
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/uniphier-system-bus.txt
@@ -0,0 +1,65 @@
+UniPhier System Bus
+
+The UniPhier System Bus is an external bus that connects on-board devices to
+the UniPhier SoC. It is a simple (semi-)parallel bus with address, data, and
+some control signals. It supports up to 8 banks (chip selects).
+
+Before any access to the bus, the bus controller must be configured; the bus
+controller registers provide the control for the address translation from the
+the System Bus to the parent bus. The needed setup includes the base address,
+the size, and some timing parameters of each bank.
+
+Required properties:
+- compatible: should be "socionext,uniphier-system-bus".
+- reg: offset and length of the register set for the bus controller device.
+- #address-cells: should be 2. The first cell is the bank number (chip
select).
+ The second cell is the address offset within the bank.
+- #size-cells: should be 1.
+- ranges: should provide a proper address translation from the System Bus to
+ the parent bus.
+
+Note:
+The address region(s) that can be assigned for the System Bus is implementation
+defined. Some SoCs can use 0x-0x0fff and 0x4000-0x4fff,
+while other SoCs can only use 0x4000-0x4fff. There might be additional
+limitations depending on SoCs and the boot mode. The address translation is
+arbitrary as long as the banks are assigned in the supported address space with
+the required alignment and they do not overlap one another.
+For example, it is possible to map:
+ bank 0 to 0x4200-0x43ff, bank 5 to 0x4600-0x46ff
+It is also possible to map:
+ bank 0 to 0x4800-0x49ff, bank 5 to 0x4400-0x44ff
+There is no reason to stick to a particular translation mapping, but the
+"ranges" property should provide a "reasonable" default that is known to work.
+The software should initialize the bus controller according to it.
+
+Example:
+
+ system-bus {
+ compatible = "socionext,uniphier-system-bus";
+ reg = <0x58c0 0x400>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <1 0x 0x4200 0x0200
+ 5 0x 0x4600 0x0100>;
+
+ ethernet@1,01f0 {
+ compatible = "smsc,lan9115";
+ reg = <1 0x01f0 0x1000>;
+ interrupts = <0 48 4>
+ phy-mode = "mii";
+ };
+
+ uart@5,0020 {
+ compatible = "ns16550a";
+ reg = <5 0x0020 0x20>;
+ interrupts = <0 49 4>
+ clock-frequency = <12288000>;
+ };
+ };
+
+In this example,
+ - the Ethernet device is connected at the offset 0x01f0 of CS1 and
+ mapped to 0x43f0 of the parent
Re: memcg uncharge page counter mismatch
On Thu, Dec 03, 2015 at 04:47:29PM +0100, Michal Hocko wrote:
> On Thu 03-12-15 15:58:50, Michal Hocko wrote:
> []
> > Warning, this looks ugly as hell.
>
> I was thinking about it some more and it seems that we should rather not
> bother with partial thp at all and keep it in the original memcg
> instead. It is way much less code and I do not think this will be too
> disruptive. Somebody should be holding the thp head, right?
>
> Minchan, does this fix the issue you are seeing.
This patch solves the issue but not sure it's right approach.
I think it could make regression that in old, we could charge
a THP page but we can't now. Whether it's trivial or not, it depends
on memcg guys.
Thanks.
> ---
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 79a29d564bff..143c933f0b81 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -4895,6 +4895,14 @@ static int mem_cgroup_move_charge_pte_range(pmd_t *pmd,
> switch (get_mctgt_type(vma, addr, ptent, )) {
> case MC_TARGET_PAGE:
> page = target.page;
> + /*
> + * We can have a part of the split pmd here. Moving it
> + * can be done but it would be too convoluted so simply
> + * ignore such a partial THP and keep it in original
> + * memcg. There should be somebody mapping the head.
> + */
> + if (PageCompound(page))
> + goto put;
> if (isolate_lru_page(page))
> goto put;
> if (!mem_cgroup_move_account(page, false,
> --
> Michal Hocko
> SUSE Labs
--
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4] fs: clear file privilege bits when mmap writing
Normally, when a user can modify a file that has setuid or setgid bits,
those bits are cleared when they are not the file owner or a member
of the group. This is enforced when using write and truncate but not
when writing to a shared mmap on the file. This could allow the file
writer to gain privileges by changing a binary without losing the
setuid/setgid/caps bits.
Changing the bits requires holding inode->i_mutex, so it cannot be done
during the page fault (due to mmap_sem being held during the fault).
Instead, clear the bits if PROT_WRITE is being used at mmap open time.
But we can't do the check in the right place inside mmap, so we have to
do it before holding mmap_sem, which means duplicating some checks, which
have to be available to the non-MMU builds too.
Signed-off-by: Kees Cook
---
v4:
- fixed email to actually deliver again, sorry for any dups!
v3:
- move outside of mmap_sem for real now, fengguang
- check return code of file_remove_privs, akpm
v2:
- move check from page fault to mmap open, jack
---
include/linux/mm.h | 1 +
mm/mmap.c | 19 ---
mm/util.c | 50 ++
3 files changed, 55 insertions(+), 15 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 00bad7793788..b264c8be7114 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1912,6 +1912,7 @@ extern unsigned long get_unmapped_area(struct file *,
unsigned long, unsigned lo
extern unsigned long mmap_region(struct file *file, unsigned long addr,
unsigned long len, vm_flags_t vm_flags, unsigned long pgoff);
+extern int do_mmap_shared_checks(struct file *file, unsigned long prot);
extern unsigned long do_mmap(struct file *file, unsigned long addr,
unsigned long len, unsigned long prot, unsigned long flags,
vm_flags_t vm_flags, unsigned long pgoff, unsigned long *populate);
diff --git a/mm/mmap.c b/mm/mmap.c
index 2ce04a649f6b..bcbe592a2c49 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1321,24 +1321,13 @@ unsigned long do_mmap(struct file *file, unsigned long
addr,
if (file) {
struct inode *inode = file_inode(file);
+ int err;
switch (flags & MAP_TYPE) {
case MAP_SHARED:
- if ((prot_WRITE) && !(file->f_mode_WRITE))
- return -EACCES;
-
- /*
-* Make sure we don't allow writing to an append-only
-* file..
-*/
- if (IS_APPEND(inode) && (file->f_mode & FMODE_WRITE))
- return -EACCES;
-
- /*
-* Make sure there are no mandatory locks on the file.
-*/
- if (locks_verify_locked(file))
- return -EAGAIN;
+ err = do_mmap_shared_checks(file, prot);
+ if (err)
+ return err;
vm_flags |= VM_SHARED | VM_MAYSHARE;
if (!(file->f_mode & FMODE_WRITE))
diff --git a/mm/util.c b/mm/util.c
index 9af1c12b310c..1882eaf33a37 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -283,6 +283,29 @@ int __weak get_user_pages_fast(unsigned long start,
}
EXPORT_SYMBOL_GPL(get_user_pages_fast);
+int do_mmap_shared_checks(struct file *file, unsigned long prot)
+{
+ struct inode *inode = file_inode(file);
+
+ if ((prot & PROT_WRITE) && !(file->f_mode & FMODE_WRITE))
+ return -EACCES;
+
+ /*
+* Make sure we don't allow writing to an append-only
+* file..
+*/
+ if (IS_APPEND(inode) && (file->f_mode & FMODE_WRITE))
+ return -EACCES;
+
+ /*
+* Make sure there are no mandatory locks on the file.
+*/
+ if (locks_verify_locked(file))
+ return -EAGAIN;
+
+ return 0;
+}
+
unsigned long vm_mmap_pgoff(struct file *file, unsigned long addr,
unsigned long len, unsigned long prot,
unsigned long flag, unsigned long pgoff)
@@ -291,6 +314,33 @@ unsigned long vm_mmap_pgoff(struct file *file, unsigned
long addr,
struct mm_struct *mm = current->mm;
unsigned long populate;
+ /*
+* If we must remove privs, we do it here since doing it during
+* page fault may be expensive and cannot hold inode->i_mutex,
+* since mm->mmap_sem is already held.
+*/
+ if (file && (flag & MAP_TYPE) == MAP_SHARED && (prot & PROT_WRITE)) {
+ struct inode *inode = file_inode(file);
+ int err;
+
+ if (!IS_NOSEC(inode)) {
+ /*
+* Make sure we can't strip privs from a file that
+* wouldn't otherwise be allowed to be mmapped.
+*/
+
Re: [PATCH 1/3] spi: spi-xilinx: Remove ISR race condition
> >> >> = >> spi: xilinx - minimize iomem reads >> >> If this IP core is accessed through bridges like PCI-e, reads are rather >> costly. Doing many reads or read-modify-writes is thus long and strenuous >> on the CPU (active waiting). >> >> The transfer workflow of this driver allows some assumptions to be made >> and >> exploited to minimize reads as much as possible. >> >> These two assumptions are made: >> - since we are in control of the CR register, cache it so we don't have >> to >> read it all the time to modify it. > > Makes sense. I have made an attempt at it can you check if you get any performance improvemets on your setup. http://www.spinics.net/lists/linux-spi/msg05963.html Thanks, Shubhrajyoti -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [dm-devel] [PATCH 0/2] Introduce the request handling for dm-crypt
On 3 December 2015 at 23:49, Mikulas Patocka wrote: > > > On Thu, 3 Dec 2015, Baolin Wang wrote: > >> On 3 December 2015 at 10:56, Baolin Wang wrote: >> > On 3 December 2015 at 03:56, Alasdair G Kergon wrote: >> >> On Wed, Dec 02, 2015 at 08:46:54PM +0800, Baolin Wang wrote: >> >>> These are the benchmarks for request based dm-crypt. Please check it. >> >> >> >> Now please put request-based dm-crypt completely to one side and focus >> >> just on the existing bio-based code. Why is it slower and what can be >> >> adjusted to improve this? >> >> >> > >> > OK. I think I find something need to be point out. >> > 1. From the IO block size test in the performance report, for the >> > request based, we can find it can not get the corresponding >> > performance if we just expand the IO size. Because In dm crypt, it >> > will map the data buffer of one request with scatterlists, and send >> > all scatterlists of one request to the encryption engine to encrypt or >> > decrypt. I found if the scatterlist list number is small and each >> > scatterlist length is bigger, it will improve the encryption speed, >> > that helps the engine palys best performance. But a big IO size does >> > not mean bigger scatterlists (maybe many scatterlists with small >> > length), that's why we can not get the corresponding performance if we >> > just expand the IO size I think. >> > >> > 2. Why bio based is slower? >> > If you understand 1, you can obviously understand the crypto engine >> > likes bigger scatterlists to improve the performance. But for bio >> > based, it only send one scatterlist (the scatterlist's length is >> > always '1 << SECTOR_SHIFT' = 512) to the crypto engine at one time. It >> > means if the bio size is 1M, the bio based will send 2048 times (evey >> > time the only one scatterlist length is 512 bytes) to crypto engine to >> > handle, which is more time-consuming and ineffective for the crypto >> > engine. But for request based, it can map the whole request with many >> > scatterlists (not just one scatterlist), and send all the scatterlists >> > to the crypto engine which can improve the performance, is it right? >> > >> > Another optimization solution I think is we can expand the scatterlist >> > entry number for bio based. >> > >> >> I did some testing about my assumption of expanding the scatterlist >> entry number for bio based. I did some modification for the bio based >> to support multiple scatterlists, then it will get the same >> performance as the request based things. >> >> 1. bio based with expanding the scatterlist entry >> time dd if=/dev/dm-0 of=/dev/null bs=64K count=16384 iflag=direct >> 1073741824 bytes (1.1 GB) copied, 94.5458 s, 11.4 MB/s >> real1m34.562s >> user0m0.030s >> sys 0m3.850s >> >> 2. Sequential read 1G with requset based: >> time dd if=/dev/dm-0 of=/dev/null bs=64K count=16384 iflag=direct >> 1073741824 bytes (1.1 GB) copied, 94.8922 s, 11.3 MB/s >> real1m34.908s >> user0m0.030s >> sys 0m4.000s > > Measuring the system time this way is completely wrong because it doesn't > account for the time spent in kernel threads. > OK. Thanks for your suggestions. > Mikulas -- Baolin.wang Best Regards -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [dm-devel] [PATCH 0/2] Introduce the request handling for dm-crypt
On 3 December 2015 at 23:47, Mikulas Patocka wrote: > > > On Thu, 3 Dec 2015, Baolin Wang wrote: > >> On 3 December 2015 at 03:56, Alasdair G Kergon wrote: >> > On Wed, Dec 02, 2015 at 08:46:54PM +0800, Baolin Wang wrote: >> >> These are the benchmarks for request based dm-crypt. Please check it. >> > >> > Now please put request-based dm-crypt completely to one side and focus >> > just on the existing bio-based code. Why is it slower and what can be >> > adjusted to improve this? >> > >> >> OK. I think I find something need to be point out. >> 1. From the IO block size test in the performance report, for the >> request based, we can find it can not get the corresponding >> performance if we just expand the IO size. Because In dm crypt, it >> will map the data buffer of one request with scatterlists, and send >> all scatterlists of one request to the encryption engine to encrypt or >> decrypt. I found if the scatterlist list number is small and each >> scatterlist length is bigger, it will improve the encryption speed, > > This optimization is only applicable to XTS mode. XTS has its weaknesses > and it is not recommended for encryption of more than 1TB of data > ( http://grouper.ieee.org/groups/1619/email/msg02357.html ) > > You can optimize bio-based dm-crypt as well (use larger encryption chunk > than 512 bytes when the mode is XTS). > > The most commonly used mode aes-cbc-essiv:sha256 can't be optimized that > way. You have to do encryption and decryption sector by sector because > every sector has different IV. Make sense. We'll optimize bio-based dm-crypt for XTS mode, and do some investigations for none XTS mode. > > Mikulas > -- Baolin.wang Best Regards -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] perf/x86/intel/uncore: Add Broadwell-EP uncore support
From: Kan Liang
The uncore subsystem for Broadwell-EP is similar to Haswell-EP.
There are some differences in pci device IDs, box number and
constraints. This patch extends the Broadwell-DE codes to support
Broadwell-EP.
Signed-off-by: Kan Liang
---
arch/x86/kernel/cpu/perf_event_intel_uncore.c | 2 +
.../x86/kernel/cpu/perf_event_intel_uncore_snbep.c | 152 -
2 files changed, 149 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
index 61215a6..b63271c 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
@@ -966,6 +966,7 @@ static int __init uncore_pci_init(void)
case 63: /* Haswell-EP */
ret = hswep_uncore_pci_init();
break;
+ case 79: /* BDX-EP */
case 86: /* BDX-DE */
ret = bdx_uncore_pci_init();
break;
@@ -1287,6 +1288,7 @@ static int __init uncore_cpu_init(void)
case 63: /* Haswell-EP */
hswep_uncore_cpu_init();
break;
+ case 79: /* BDX-EP */
case 86: /* BDX-DE */
bdx_uncore_cpu_init();
break;
diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore_snbep.c
b/arch/x86/kernel/cpu/perf_event_intel_uncore_snbep.c
index f0f4fcb..f2ddfcc 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore_snbep.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore_snbep.c
@@ -2338,7 +2338,7 @@ int hswep_uncore_pci_init(void)
}
/* end of Haswell-EP uncore support */
-/* BDX-DE uncore support */
+/* BDX uncore support */
static struct intel_uncore_type bdx_uncore_ubox = {
.name = "ubox",
@@ -2360,13 +2360,14 @@ static struct event_constraint
bdx_uncore_cbox_constraints[] = {
UNCORE_EVENT_CONSTRAINT(0x09, 0x3),
UNCORE_EVENT_CONSTRAINT(0x11, 0x1),
UNCORE_EVENT_CONSTRAINT(0x36, 0x1),
+ UNCORE_EVENT_CONSTRAINT(0x3e, 0x1),
EVENT_CONSTRAINT_END
};
static struct intel_uncore_type bdx_uncore_cbox = {
.name = "cbox",
.num_counters = 4,
- .num_boxes = 8,
+ .num_boxes = 24,
.perf_ctr_bits = 48,
.event_ctl = HSWEP_C0_MSR_PMON_CTL0,
.perf_ctr = HSWEP_C0_MSR_PMON_CTR0,
@@ -2379,9 +2380,24 @@ static struct intel_uncore_type bdx_uncore_cbox = {
.format_group = _uncore_cbox_format_group,
};
+static struct intel_uncore_type bdx_uncore_sbox = {
+ .name = "sbox",
+ .num_counters = 4,
+ .num_boxes = 4,
+ .perf_ctr_bits = 48,
+ .event_ctl = HSWEP_S0_MSR_PMON_CTL0,
+ .perf_ctr = HSWEP_S0_MSR_PMON_CTR0,
+ .event_mask = HSWEP_S_MSR_PMON_RAW_EVENT_MASK,
+ .box_ctl= HSWEP_S0_MSR_PMON_BOX_CTL,
+ .msr_offset = HSWEP_SBOX_MSR_OFFSET,
+ .ops= _uncore_sbox_msr_ops,
+ .format_group = _uncore_sbox_format_group,
+};
+
static struct intel_uncore_type *bdx_msr_uncores[] = {
_uncore_ubox,
_uncore_cbox,
+ _uncore_sbox,
_uncore_pcu,
NULL,
};
@@ -2396,7 +2412,7 @@ void bdx_uncore_cpu_init(void)
static struct intel_uncore_type bdx_uncore_ha = {
.name = "ha",
.num_counters = 4,
- .num_boxes = 1,
+ .num_boxes = 2,
.perf_ctr_bits = 48,
SNBEP_UNCORE_PCI_COMMON_INIT(),
};
@@ -2404,7 +2420,7 @@ static struct intel_uncore_type bdx_uncore_ha = {
static struct intel_uncore_type bdx_uncore_imc = {
.name = "imc",
.num_counters = 5,
- .num_boxes = 2,
+ .num_boxes = 8,
.perf_ctr_bits = 48,
.fixed_ctr_bits = 48,
.fixed_ctr = SNBEP_MC_CHy_PCI_PMON_FIXED_CTR,
@@ -2424,6 +2440,19 @@ static struct intel_uncore_type bdx_uncore_irp = {
.format_group = _uncore_format_group,
};
+static struct intel_uncore_type bdx_uncore_qpi = {
+ .name = "qpi",
+ .num_counters = 4,
+ .num_boxes = 3,
+ .perf_ctr_bits = 48,
+ .perf_ctr = SNBEP_PCI_PMON_CTR0,
+ .event_ctl = SNBEP_PCI_PMON_CTL0,
+ .event_mask = SNBEP_QPI_PCI_PMON_RAW_EVENT_MASK,
+ .box_ctl= SNBEP_PCI_PMON_BOX_CTL,
+ .num_shared_regs= 1,
+ .ops= _uncore_qpi_ops,
+ .format_group = _uncore_qpi_format_group,
+};
static struct event_constraint bdx_uncore_r2pcie_constraints[] = {
UNCORE_EVENT_CONSTRAINT(0x10, 0x3),
@@ -2432,6 +2461,8 @@ static struct event_constraint
bdx_uncore_r2pcie_constraints[] = {
Re: [PATCH v2 3/9] ARM: hisi: enable Hi3519 soc
Hi Arnd,
On 2015/12/3 17:40, Arnd Bergmann wrote:
> On Thursday 03 December 2015 10:42:45 Jiancheng Xue wrote:
>> --- a/arch/arm/mach-hisi/Kconfig
>> +++ b/arch/arm/mach-hisi/Kconfig
>> @@ -12,6 +12,14 @@ if ARCH_HISI
>>
>> menu "Hisilicon platform type"
>>
>> +config ARCH_HI3519
>> + bool "Hisilicon Hi3519 Soc" if ARCH_MULTI_V7
>> + select HAVE_ARM_ARCH_TIMER
>> + select ARCH_HAS_RESET_CONTROLLER
>> +
>> + help
>> + Support for Hisilicon Hi3519 Soc
>> +
>> config ARCH_HI3xxx
>> bool "Hisilicon Hi36xx family" if ARCH_MULTI_V7
>> select CACHE_L2X0
>
> Do those need to be separate? I would just extend the Hi36xx
> to cover all Hi3xxx, if nothing in the platform code really
> depends on this.
For HI3519, there is really no special platform code. But HI35xx and HI36xx soc
families
belong to different product lines in hisilicon. HI35xx family also composes of
various
architectures socs(single core, smp and big-little). So I think it may be clear
to have
separate arch definitions.
Could you give me more suggestions about this? Thank you!
>> +
>> +static const char *const hi3519_compat[] __initconst = {
>> + "hisilicon,hi3519",
>> + NULL,
>> +};
>> +
>> +DT_MACHINE_START(HI3519_DT, "Hisilicon Hi3519 (Flattened Device Tree)")
>> + .dt_compat = hi3519_compat,
>> +MACHINE_END
>
> Also drop the "(Flattened Device Tree)" part of the name, we don't
> support any other kind anyway.
OK.
>
> Arnd
>
> .
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] rtc: fix overflow and incorrect calculation in rtc_time64_to_tm
At some point after humans go extinct and robots cotrol the world, dividing
he time64_t by 86400 to extract the days will overflow a 32bit integer,
leading to incorrect conversion into rtc_time in rtc_time64_to_tm().
Signed-off-by: Sasha Levin
---
drivers/rtc/rtc-lib.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/rtc/rtc-lib.c b/drivers/rtc/rtc-lib.c
index e6bfb9c..cafae93 100644
--- a/drivers/rtc/rtc-lib.c
+++ b/drivers/rtc/rtc-lib.c
@@ -53,12 +53,11 @@ EXPORT_SYMBOL(rtc_year_days);
void rtc_time64_to_tm(time64_t time, struct rtc_time *tm)
{
unsigned int month, year;
- unsigned long secs;
- int days;
+ int secs;
+ time64_t days;
/* time must be positive */
- days = div_s64(time, 86400);
- secs = time - (unsigned int) days * 86400;
+ days = div_s64_rem(time, 86400, );
/* day of the week, 1970-01-01 was a Thursday */
tm->tm_wday = (days + 4) % 7;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/9] 8250/Kconfig: add config option CONFIG_SERIAL_8250_AMD
Add config option CONFIG_SERIAL_8250_AMD in use of AMD carrizo. Because carrizo's UART DMA device is an amba device, it selects ARM_AMBA option. Anything uses amba devices must select ARM_AMBA. Signed-off-by: Wang Hongcheng --- drivers/tty/serial/8250/Kconfig | 8 1 file changed, 8 insertions(+) diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig index 6412f14..d9717c1 100644 --- a/drivers/tty/serial/8250/Kconfig +++ b/drivers/tty/serial/8250/Kconfig @@ -378,3 +378,11 @@ config SERIAL_8250_MID Selecting this option will enable handling of the extra features present on the UART found on Intel Medfield SOC and various other Intel platforms. + +config SERIAL_8250_AMD +bool "AMD carrizo serial port support" +depends on SERIAL_8250 + select ARM_AMBA +help + If you have a Carrizo based board and want to use the + serial port, say Y to this option. If unsure, say N. -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 9/9] iommu/amd: Add ACPI HID named devices IOMMU driver support
From: Wan Zongshun
AMD UART is a ACPI HID named device, it also is none-pci device,
currently, iommu driver only supports pci device, so UART DMA did
not work at current AMD IOMMU driver.
AMD reused 8250 serial driver and ARM PL330 DMA engine driver,
since AMD uart and dma ips are compatible with 8250 and pl330.
When those non-pci functions do DMA, they still generate some
sort of fake PCI like BDF(bus:dev:fun) id with the request to
work properly with IOMMU.
According to above descriptions, this patch was designed:
1. Add ivrs_acpihid kernel boot parameter interface, map HID:UID
to BDF id, those ids were hardcoded by AMD.
2. We never create new group for none-pci device, just adhere them
to existing group that has same bus and device id.
3. Add amd iommu callbacks for amba type bus, since pl330 driver
transferred amba_device->dev into dma_map_single.
Signed-off-by: Wan Zongshun
---
drivers/iommu/amd_iommu.c | 165 +++-
drivers/iommu/amd_iommu_init.c | 123 +-
drivers/iommu/amd_iommu_types.h | 11 +++
3 files changed, 279 insertions(+), 20 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 8b2be1e..13581c0 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -71,6 +72,7 @@ static DEFINE_SPINLOCK(dev_data_list_lock);
LIST_HEAD(ioapic_map);
LIST_HEAD(hpet_map);
+LIST_HEAD(acpihid_map);
/*
* Domain for untranslated devices - only allocated
@@ -174,13 +176,71 @@ static struct iommu_dev_data *find_dev_data(u16 devid)
return dev_data;
}
-static inline u16 get_device_id(struct device *dev)
+static inline int match_hid_uid(struct device *dev,
+ struct acpihid_map *entry)
+{
+ const u8 *hid, *uid;
+
+ hid = acpi_device_hid(ACPI_COMPANION(dev));
+ uid = acpi_device_uid(ACPI_COMPANION(dev));
+
+ if (!strcmp(hid, entry->hid) && !strcmp(uid, entry->uid))
+ return 0;
+
+ return -ENODEV;
+}
+
+static inline u16 get_pci_device_id(struct device *dev)
{
struct pci_dev *pdev = to_pci_dev(dev);
return PCI_DEVID(pdev->bus->number, pdev->devfn);
}
+static inline int get_acpihid_device_id(struct device *dev)
+{
+ struct acpihid_map *entry;
+
+ list_for_each_entry(entry, _map, list) {
+ if (!match_hid_uid(dev, entry))
+ return entry->devid;
+ }
+ return -EINVAL;
+}
+
+static inline u16 get_device_id(struct device *dev)
+{
+ if (dev_is_pci(dev))
+ return get_pci_device_id(dev);
+ else
+ return get_acpihid_device_id(dev);
+}
+
+static void find_acpihid_group_by_rootid(struct device *dev,
+ struct iommu_group *group)
+{
+ struct acpihid_map *entry;
+
+ list_for_each_entry(entry, _map, list) {
+ if (entry->group)
+ continue;
+ if (entry->root_devid == get_device_id(dev))
+ entry->group = group;
+ }
+}
+
+static struct iommu_group *find_acpihid_group_by_devid(struct device *dev)
+{
+ struct acpihid_map *entry;
+
+ list_for_each_entry(entry, _map, list) {
+ if (!match_hid_uid(dev, entry))
+ return entry->group;
+ }
+
+ return NULL;
+}
+
static struct iommu_dev_data *get_dev_data(struct device *dev)
{
return dev->archdata.iommu;
@@ -260,7 +320,7 @@ static bool check_device(struct device *dev)
return false;
/* No PCI device */
- if (!dev_is_pci(dev))
+ if (!dev_is_pci(dev) && (get_acpihid_device_id(dev) < 0))
return false;
devid = get_device_id(dev);
@@ -285,6 +345,8 @@ static void init_iommu_group(struct device *dev)
if (IS_ERR(group))
return;
+ find_acpihid_group_by_rootid(dev, group);
+
domain = iommu_group_default_domain(group);
if (!domain)
goto out;
@@ -2071,29 +2133,33 @@ static bool pci_pri_tlp_required(struct pci_dev *pdev)
static int attach_device(struct device *dev,
struct protection_domain *domain)
{
- struct pci_dev *pdev = to_pci_dev(dev);
struct iommu_dev_data *dev_data;
unsigned long flags;
int ret;
dev_data = get_dev_data(dev);
- if (domain->flags & PD_IOMMUV2_MASK) {
- if (!dev_data->passthrough)
- return -EINVAL;
+ if (dev_is_pci(dev)) {
+
+ struct pci_dev *pdev = to_pci_dev(dev);
- if (dev_data->iommu_v2) {
- if (pdev_iommuv2_enable(pdev) != 0)
+ if (domain->flags & PD_IOMMUV2_MASK) {
+ if (!dev_data->passthrough)
[PATCH v3 1/2] arm64: ftrace: stop using kstop_machine to enable/disable tracing
For ftrace on arm64, kstop_machine which is hugely disruptive
to a running system is not needed to convert nops to ftrace calls
or back, because that to be modified instrucions, that NOP, B or BL,
are all safe instructions which called "concurrent modification
and execution of instructions", that can be executed by one
thread of execution as they are being modified by another thread
of execution without requiring explicit synchronization.
Signed-off-by: Li Bin
Reviewed-by: Steven Rostedt
---
arch/arm64/kernel/ftrace.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
index c851be7..9669b33 100644
--- a/arch/arm64/kernel/ftrace.c
+++ b/arch/arm64/kernel/ftrace.c
@@ -93,6 +93,11 @@ int ftrace_make_nop(struct module *mod, struct dyn_ftrace
*rec,
return ftrace_modify_code(pc, old, new, true);
}
+void arch_ftrace_update_code(int command)
+{
+ ftrace_modify_all_code(command);
+}
+
int __init ftrace_dyn_arch_init(void)
{
return 0;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/9] dmaengine:pl330: set segment_boundary_mask = 0cffffffff
Because amd iommu and software iommu need this mask.For example, if we use software iommu without this mask, we will get 'Out of SW-IOMMU space' error, when calling swiotlb_map_page function. Signed-off-by: Wan Zongshun Signed-off-by: Wang Hongcheng --- drivers/dma/pl330.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c index 9d7af0d..fb46fdf 100644 --- a/drivers/dma/pl330.c +++ b/drivers/dma/pl330.c @@ -2966,6 +2966,10 @@ pl330_probe(struct amba_device *adev, const struct amba_id *id) if (ret) dev_err(>dev, "unable to set the seg size\n"); + dev_info(>dev, "set the seg boundary\n"); + ret = dma_set_seg_boundary(>dev, 0x); + if (ret) + dev_err(>dev, "unable to set the seg boundary\n"); dev_info(>dev, "Loaded driver for PL330 DMAC-%x\n", adev->periphid); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/9] ACPI: add struct acpi_amba_quirk for AMD pl330 specific device config
AMD pl330 is a UART DMA device, it shares one ACPI item with UART. So
a platform device and an acpi device will be created according to
AMD0020 ACPI dev. And its mem base address must have an offset. As a
result, MULTI_ATTACHED_QUIRK and MULTI_ATTACHED_QUIRK are used.
Signed-off-by: Wang Hongcheng
---
drivers/acpi/acpi_amba.c | 31 +++
drivers/acpi/acpi_apd.c | 56 +---
include/linux/acpi.h | 13 +--
3 files changed, 81 insertions(+), 19 deletions(-)
diff --git a/drivers/acpi/acpi_amba.c b/drivers/acpi/acpi_amba.c
index 4f0366a..8a5269c 100644
--- a/drivers/acpi/acpi_amba.c
+++ b/drivers/acpi/acpi_amba.c
@@ -31,6 +31,8 @@ ACPI_MODULE_NAME("amba");
* @periphid: AMBA device periphid.
* @fixed_rate: Clock frequency.
* @pdata: Platform data specific to the device.
+ * @quirk: Specific device config, including device multiattach.
+ * and mem base offset.
*
* Check if the given @adev can be represented as an AMBA device and, if
* that's the case, create and register an AMBA device, populate its
@@ -42,7 +44,8 @@ ACPI_MODULE_NAME("amba");
struct amba_device *acpi_create_amba_device(struct acpi_device *adev,
unsigned int periphid,
unsigned long fixed_rate,
- void *pdata)
+ void *pdata,
+ struct acpi_amba_quirk *quirk)
{
struct amba_device *amba_dev = NULL;
struct device *parent;
@@ -54,12 +57,14 @@ struct amba_device *acpi_create_amba_device(struct
acpi_device *adev,
unsigned int i;
unsigned int irq[AMBA_NR_IRQS];
struct clk *clk = ERR_PTR(-ENODEV);
+ char amba_devname[100];
/*
* If the ACPI node already has a physical device attached,
-* skip it.
+* skip it. Except some special devices such as AMD0020 which
+* needs attach physical devices two times.
*/
- if (adev->physical_node_count)
+ if (adev->physical_node_count && !(quirk->quirk & MULTI_ATTACHED_QUIRK))
return NULL;
INIT_LIST_HEAD(_list);
@@ -85,7 +90,24 @@ struct amba_device *acpi_create_amba_device(struct
acpi_device *adev,
memcpy(resource, rentry->res, sizeof(struct resource));
}
- amba_dev = amba_device_alloc(dev_name(>dev),
+ /*
+* The memory address of AMD pl330 has an offset of ACPI
+* mem resource.
+*/
+ if (quirk->quirk & BASE_OFFSET_QUIRK)
+ resource->start += quirk->base_offset;
+
+ /*
+* If the ACPI device already has a node attached. It must be
+* renamed.
+*/
+ if (quirk->quirk & MULTI_ATTACHED_QUIRK)
+ sprintf(amba_devname, "%s%s", dev_name(>dev), "DMA");
+ else
+ memcpy(amba_devname, dev_name(>dev),
+ strlen(dev_name(>dev)));
+
+ amba_dev = amba_device_alloc(amba_devname,
resource->start,
resource_size(resource));
@@ -136,6 +158,7 @@ struct amba_device *acpi_create_amba_device(struct
acpi_device *adev,
if (ret)
goto amba_register_err;
+ amba_dev->dev.init_name = NULL;
ret = amba_device_add(amba_dev, resource);
if (ret)
goto amba_register_err;
diff --git a/drivers/acpi/acpi_apd.c b/drivers/acpi/acpi_apd.c
index a450e7a..eb3316a 100644
--- a/drivers/acpi/acpi_apd.c
+++ b/drivers/acpi/acpi_apd.c
@@ -3,7 +3,8 @@
*
* Copyright (c) 2014,2015 AMD Corporation.
* Authors: Ken Xue
- * Wu, Jeff
+ * Jeff Wu <15618388...@163.com>
+ * Wang Hongcheng
*
* 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
@@ -17,6 +18,10 @@
#include
#include
#include
+#include
+#include
+#include
+#include
#include "internal.h"
@@ -31,14 +36,15 @@ struct apd_private_data;
#define ACPI_APD_PMBIT(1)
/**
- * struct apd_device_desc - a descriptor for apd device
- * @flags: device flags like %ACPI_APD_SYSFS, %ACPI_APD_PM
+ * struct apd_device_desc - a descriptor for apd device.
+ * @flags: device flags like %ACPI_APD_SYSFS, %ACPI_APD_PM;
* @fixed_clk_rate: fixed rate input clock source for acpi device;
- * 0 means no fixed rate input clock source
- * @setup: a hook routine to set device resource during create platform device
+ *0 means no fixed rate input clock source;
+ * @clk_con_id: name of input clock source;
+ * @setup: a hook routine to set device resource during create platform device.
*
- * Device description defined as acpi_device_id.driver_data
- */
+ * Device description defined as acpi_device_id.driver_data.
+*/
struct apd_device_desc
[PATCH 4/9] dmaengine: pl330: add new items for pl330 private data
has_no_cap_mask means this device has no preset cap mask.
mcbuf_sz means bytes to allocate for MC buffer.
flags is for irq sharing, default is non-shared, in AMD
Carrizo, pl330 shares IRQ with its corresponding UART device.
Signed-off-by: Wang Hongcheng
---
drivers/acpi/acpi_apd.c| 13 -
drivers/dma/pl330.c| 19 +--
include/linux/amba/pl330.h | 3 +++
3 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/drivers/acpi/acpi_apd.c b/drivers/acpi/acpi_apd.c
index eb3316a..7a582f5 100644
--- a/drivers/acpi/acpi_apd.c
+++ b/drivers/acpi/acpi_apd.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include "internal.h"
@@ -35,6 +36,16 @@ struct apd_private_data;
#define ACPI_APD_SYSFS BIT(0)
#define ACPI_APD_PMBIT(1)
+static u8 peri_id[2] = { 0, 1 };
+
+static struct dma_pl330_platdata amd_pl330 = {
+ .nr_valid_peri = 2,
+ .peri_id = peri_id,
+ .has_no_cap_mask = true,
+ .mcbuf_sz = 0,
+ .flags = IRQF_SHARED,
+};
+
/**
* struct apd_device_desc - a descriptor for apd device.
* @flags: device flags like %ACPI_APD_SYSFS, %ACPI_APD_PM;
@@ -146,7 +157,7 @@ static int acpi_apd_create_device(struct acpi_device *adev,
amba_dev = acpi_create_amba_device(pdata->adev, 0x00041330,
4800,
- NULL,
+ _pl330,
_quirks);
if (IS_ERR_OR_NULL(amba_dev))
goto err_out;
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 17ee758..8300969 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -26,6 +26,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -488,6 +490,9 @@ struct pl330_dmac {
/* Peripheral channels connected to this DMAC */
unsigned int num_peripherals;
struct dma_pl330_chan *peripherals; /* keep at end */
+
+ /*IRQ register flags */
+ unsigned int flags;
};
struct dma_pl330_desc {
@@ -2800,6 +2805,8 @@ pl330_probe(struct amba_device *adev, const struct
amba_id *id)
pl330->mcbufsz = pdat ? pdat->mcbuf_sz : 0;
+ pl330->flags = pdat ? pdat->flags : IRQF_TRIGGER_NONE;
+
res = >res;
pl330->base = devm_ioremap_resource(>dev, res);
if (IS_ERR(pl330->base))
@@ -2811,7 +2818,7 @@ pl330_probe(struct amba_device *adev, const struct
amba_id *id)
irq = adev->irq[i];
if (irq) {
ret = devm_request_irq(>dev, irq,
- pl330_irq_handler, 0,
+ pl330_irq_handler, pl330->flags,
dev_name(>dev), pl330);
if (ret)
return ret;
@@ -2870,7 +2877,7 @@ pl330_probe(struct amba_device *adev, const struct
amba_id *id)
list_add_tail(>chan.device_node, >channels);
}
- if (pdat) {
+ if (pdat && !pdat->has_no_cap_mask) {
pd->cap_mask = pdat->cap_mask;
} else {
dma_cap_set(DMA_MEMCPY, pd->cap_mask);
@@ -2923,11 +2930,11 @@ pl330_probe(struct amba_device *adev, const struct
amba_id *id)
dev_info(>dev,
- "Loaded driver for PL330 DMAC-%x\n", adev->periphid);
+"Loaded driver for PL330 DMAC-%x\n", adev->periphid);
dev_info(>dev,
- "\tDBUFF-%ux%ubytes Num_Chans-%u Num_Peri-%u Num_Events-%u\n",
- pcfg->data_buf_dep, pcfg->data_bus_width / 8, pcfg->num_chan,
- pcfg->num_peri, pcfg->num_events);
+"\tDBUFF-%ux%ubytes Num_Chans-%u Num_Peri-%u Num_Events-%u\n",
+pcfg->data_buf_dep, pcfg->data_bus_width / 8, pcfg->num_chan,
+pcfg->num_peri, pcfg->num_events);
pm_runtime_irq_safe(>dev);
pm_runtime_use_autosuspend(>dev);
diff --git a/include/linux/amba/pl330.h b/include/linux/amba/pl330.h
index fe93758..605d00f 100644
--- a/include/linux/amba/pl330.h
+++ b/include/linux/amba/pl330.h
@@ -26,9 +26,12 @@ struct dma_pl330_platdata {
/* Array of valid peripherals */
u8 *peri_id;
/* Operational capabilities */
+ bool has_no_cap_mask;
dma_cap_mask_t cap_mask;
/* Bytes to allocate for MC buffer */
unsigned mcbuf_sz;
+ /*flags for irq sharing, default is non-shared*/
+ unsigned flags;
};
extern bool pl330_filter(struct dma_chan *chan, void *param);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/2] arm64: stop using kstop_machine for ftrace
v2: Based on the comments from Will and Steve, 1. Modify the commit message 2. Fix the misleading comments for ftrace_modify_code v3: Modify the comments again based on the comment from Steve. Link: https://lkml.org/lkml/2015/12/3/422 Li Bin (2): arm64: ftrace: stop using kstop_machine to enable/disable tracing arm64: ftrace: fix the comments for ftrace_modify_code arch/arm64/kernel/ftrace.c | 16 ++-- 1 files changed, 10 insertions(+), 6 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/9] Serial:8250: New Port Type PORT_AMD_8250
Set a new port type for AMD Carrizo. Add has_pl330_dma to 8250_dw's
private data and init fcr,ier as well as dma rx size.
Signed-off-by: Wang Hongcheng
---
drivers/acpi/acpi_apd.c | 10 ++
drivers/tty/serial/8250/8250_dw.c | 16
drivers/tty/serial/8250/8250_port.c | 9 +
include/linux/serial_8250.h | 4
include/uapi/linux/serial_core.h| 3 ++-
include/uapi/linux/serial_reg.h | 2 ++
6 files changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/acpi_apd.c b/drivers/acpi/acpi_apd.c
index 906a20f..787f477 100644
--- a/drivers/acpi/acpi_apd.c
+++ b/drivers/acpi/acpi_apd.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include "internal.h"
@@ -49,6 +50,10 @@ static struct dma_pl330_platdata amd_pl330 = {
.acpi_xlate_filter = apd_acpi_xlate_filter,
};
+static struct plat_dw8250_data amd_dw8250 = {
+ .has_pl330_dma = 1,
+};
+
/**
* struct apd_device_desc - a descriptor for apd device.
* @flags: device flags like %ACPI_APD_SYSFS, %ACPI_APD_PM;
@@ -164,6 +169,11 @@ static int acpi_apd_create_device(struct acpi_device *adev,
goto err_out;
if (!strncmp(pdev->name, "AMD0020", 7)) {
+ ret = platform_device_add_data(pdev, _dw8250,
+ sizeof(amd_dw8250));
+ if (ret)
+ goto err_out;
+
memset(_quirks, 0, sizeof(amba_quirks));
setup_quirks(pdev, _quirks);
diff --git a/drivers/tty/serial/8250/8250_dw.c
b/drivers/tty/serial/8250/8250_dw.c
index a5d319e..a5ae9b6 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -66,6 +66,8 @@ struct dw8250_data {
unsigned intskip_autocfg:1;
unsigned intuart_16550_compatible:1;
+
+ unsignedhas_pl330_dma:1;
};
#define BYT_PRV_CLK0x800
@@ -304,6 +306,7 @@ static void dw8250_setup_port(struct uart_port *p)
{
struct uart_8250_port *up = up_to_u8250p(p);
u32 reg;
+ struct dw8250_data *d = p->private_data;
/*
* If the Component Version Register returns zero, we know that
@@ -326,6 +329,16 @@ static void dw8250_setup_port(struct uart_port *p)
p->flags |= UPF_FIXED_TYPE;
p->fifosize = DW_UART_CPR_FIFO_SIZE(reg);
up->capabilities = UART_CAP_FIFO;
+ if (d->has_pl330_dma) {
+ p->type = PORT_AMD_8250;
+ p->flags |= UPF_SHARE_IRQ;
+
+ up->ier |= UART_IER_PTIME | UART_IER_THRI |
+ UART_IER_RLSI | UART_IER_RDI;
+ up->fcr |= UART_FCR_R_TRIG_10 | UART_FCR_T_TRIG_11 |
+ UART_FCR_DMA_SELECT;
+ up->tx_loadsz = p->fifosize / 2;
+ }
}
if (reg & DW_UART_CPR_AFCE_MODE)
@@ -339,6 +352,7 @@ static int dw8250_probe(struct platform_device *pdev)
int irq = platform_get_irq(pdev, 0);
struct uart_port *p =
struct dw8250_data *data;
+ struct plat_dw8250_data *pdata = dev_get_platdata(>dev);
int err;
u32 val;
@@ -468,6 +482,7 @@ static int dw8250_probe(struct platform_device *pdev)
p->handle_irq = NULL;
}
+ data->has_pl330_dma = pdata ? pdata->has_pl330_dma : 0;
if (!data->skip_autocfg)
dw8250_setup_port(p);
@@ -475,6 +490,7 @@ static int dw8250_probe(struct platform_device *pdev)
if (p->fifosize) {
data->dma.rxconf.src_maxburst = p->fifosize / 4;
data->dma.txconf.dst_maxburst = p->fifosize / 4;
+ data->dma.rx_size = data->has_pl330_dma ? (p->fifosize / 2 + 2)
: 0;
uart.dma = >dma;
}
diff --git a/drivers/tty/serial/8250/8250_port.c
b/drivers/tty/serial/8250/8250_port.c
index 52d82d2..b258edc 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -269,6 +269,15 @@ configured less than Maximum supported fifo bytes */
.rxtrig_bytes = {1, 4, 8, 14},
.flags = UART_CAP_FIFO,
},
+ [PORT_AMD_8250] = {
+ .name = "AMD_8250",
+ .fifo_size = 256,
+ .tx_loadsz = 128,
+ .fcr= UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10 |
+ UART_FCR_T_TRIG_11 | UART_FCR_DMA_SELECT,
+ .rxtrig_bytes = {1, 4, 8},
+ .flags = UART_CAP_FIFO,
+ },
};
/* Uart divisor latch read */
diff --git a/include/linux/serial_8250.h b/include/linux/serial_8250.h
index faa0e03..4652783 100644
--- a/include/linux/serial_8250.h
+++ b/include/linux/serial_8250.h
@@ -42,6 +42,10 @@ struct plat_serial8250_port {
void
[PATCH 0/9] 8250: AMD Carrizo UART PL300 DMA enablement
Hi all, As AMD carrizo UART device is compatible with 8250 and has pl330 DMA IP, our uart driver is serial:8250 and DMA engines are registered by driver/dma/pl330. The following patches are made, in order to enable DMA. Firstly, we add an universal ACPI amba glue layer to create an amba device based on ACPI table. Then we alter 8250/Kconfig to support AMD 8250 device and add quirk for AMD specific request. Secondly, since pl330 driver only provides dma engine for platform devices, we add an acpi dma engine interface. Then we add a new port type for AMD carrizo and set UART registers and dma rx size as hardware requirement. In the end, we make our IOMMU driver to support non-pci device, so UART DMA really works. Thanks, Hongcheng Huang Rui (1): ACPI: Add support for AMBA bus type Wan Zongshun (2): Documentation: Add ivrs_acpihid kernel parameter description iommu/amd: Add ACPI HID named devices IOMMU driver support Wang Hongcheng (6): 8250/Kconfig: add config option CONFIG_SERIAL_8250_AMD ACPI: add struct acpi_amba_quirk for AMD pl330 specific device config dmaengine: pl330: add new items for pl330 private data dmaengine: pl330: provide ACPI dmaengine interface dmaengine:pl330: set segment_boundary_mask = 0c Serial:8250: New Port Type PORT_AMD_8250 Documentation/kernel-parameters.txt | 7 ++ drivers/acpi/Makefile | 1 + drivers/acpi/acpi_amba.c| 180 drivers/acpi/acpi_apd.c | 89 +++--- drivers/dma/pl330.c | 61 ++-- drivers/iommu/amd_iommu.c | 165 + drivers/iommu/amd_iommu_init.c | 123 +++- drivers/iommu/amd_iommu_types.h | 11 +++ drivers/tty/serial/8250/8250_dw.c | 16 drivers/tty/serial/8250/8250_port.c | 9 ++ drivers/tty/serial/8250/Kconfig | 8 ++ include/linux/acpi.h| 30 ++ include/linux/amba/pl330.h | 4 + include/linux/serial_8250.h | 4 + include/uapi/linux/serial_core.h| 3 +- include/uapi/linux/serial_reg.h | 2 + 16 files changed, 673 insertions(+), 40 deletions(-) create mode 100644 drivers/acpi/acpi_amba.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/9] dmaengine: pl330: provide ACPI dmaengine interface
register acpi_dma controller, so ACPI devices can request pl330 DMA
channel.
A filter is added in private data for Carrizo specific hardware
design
Signed-off-by: Wang Hongcheng
---
drivers/acpi/acpi_apd.c| 12
drivers/dma/pl330.c| 38 ++
include/linux/amba/pl330.h | 1 +
3 files changed, 51 insertions(+)
diff --git a/drivers/acpi/acpi_apd.c b/drivers/acpi/acpi_apd.c
index 7a582f5..906a20f 100644
--- a/drivers/acpi/acpi_apd.c
+++ b/drivers/acpi/acpi_apd.c
@@ -38,12 +38,15 @@ struct apd_private_data;
static u8 peri_id[2] = { 0, 1 };
+static int apd_acpi_xlate_filter(int slave_id, struct device *dev);
+
static struct dma_pl330_platdata amd_pl330 = {
.nr_valid_peri = 2,
.peri_id = peri_id,
.has_no_cap_mask = true,
.mcbuf_sz = 0,
.flags = IRQF_SHARED,
+ .acpi_xlate_filter = apd_acpi_xlate_filter,
};
/**
@@ -68,6 +71,15 @@ struct apd_private_data {
const struct apd_device_desc *dev_desc;
};
+int apd_acpi_xlate_filter(int slave_id, struct device *dev)
+{
+ if (((slave_id == 1) && (!strcmp(dev_name(dev), "AMD0020:00DMA")))
+ || ((slave_id == 2) && (!strcmp(dev_name(dev), "AMD0020:01DMA"
+ return 0;
+
+ return 1;
+}
+
#ifdef CONFIG_X86_AMD_PLATFORM_DEVICE
#define APD_ADDR(desc) ((unsigned long))
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 8300969..9d7af0d 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2079,6 +2079,35 @@ static struct dma_chan *of_dma_pl330_xlate(struct
of_phandle_args *dma_spec,
return dma_get_slave_channel(>peripherals[chan_id].chan);
}
+static struct dma_chan *acpi_dma_pl330_xlate(struct acpi_dma_spec *dma_spec,
+struct acpi_dma *adma)
+{
+ struct pl330_dmac *pl330 = adma->data;
+ struct dma_pl330_platdata *pdat;
+ unsigned int chan_id;
+ int ret;
+
+ if (!dma_spec)
+ return NULL;
+
+ if (!adma)
+ return NULL;
+
+ pdat = dev_get_platdata(adma->dev);
+
+ chan_id = dma_spec->chan_id;
+ if (chan_id >= pl330->num_peripherals)
+ return NULL;
+
+ if (pdat->acpi_xlate_filter) {
+ ret = pdat->acpi_xlate_filter(dma_spec->slave_id, adma->dev);
+ if (ret)
+ return NULL;
+ }
+
+ return dma_get_slave_channel(>peripherals[chan_id].chan);
+}
+
static int pl330_alloc_chan_resources(struct dma_chan *chan)
{
struct dma_pl330_chan *pch = to_pchan(chan);
@@ -2918,6 +2947,15 @@ pl330_probe(struct amba_device *adev, const struct
amba_id *id)
}
}
+ if (ACPI_HANDLE(>dev)) {
+ ret = acpi_dma_controller_register(>dev,
+ acpi_dma_pl330_xlate, pl330);
+ if (ret) {
+ dev_err(>dev,
+ "unable to register DMA to the generic ACPI DMA
helpers\n");
+ }
+ }
+
adev->dev.dma_parms = >dma_parms;
/*
diff --git a/include/linux/amba/pl330.h b/include/linux/amba/pl330.h
index 605d00f..85bebbb 100644
--- a/include/linux/amba/pl330.h
+++ b/include/linux/amba/pl330.h
@@ -32,6 +32,7 @@ struct dma_pl330_platdata {
unsigned mcbuf_sz;
/*flags for irq sharing, default is non-shared*/
unsigned flags;
+ int (*acpi_xlate_filter)(int slave_id, struct device *dev);
};
extern bool pl330_filter(struct dma_chan *chan, void *param);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/9] ACPI: Add support for AMBA bus type
From: Huang Rui
Inspired by acpi platform bus type, to make driver "porting" more
straightforward, this patch introduces ACPI support to the AMBA bus
type. Instead of writing ACPI "glue" drivers for the exiting AMBA
drivers.
In the subsequent patches, we will use this function to support pl330
AMBA driver.
Signed-off-by: Huang Rui
Signed-off-by: Wang Hongcheng
---
drivers/acpi/Makefile| 1 +
drivers/acpi/acpi_amba.c | 157 +++
include/linux/acpi.h | 21 +++
3 files changed, 179 insertions(+)
create mode 100644 drivers/acpi/acpi_amba.c
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 675eaf3..7d84446 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -42,6 +42,7 @@ acpi-$(CONFIG_ACPI_DOCK) += dock.o
acpi-y += pci_root.o pci_link.o pci_irq.o
acpi-y += acpi_lpss.o acpi_apd.o
acpi-y += acpi_platform.o
+acpi-$(CONFIG_ARM_AMBA)+= acpi_amba.o
acpi-y += acpi_pnp.o
acpi-y += int340x_thermal.o
acpi-y += power.o
diff --git a/drivers/acpi/acpi_amba.c b/drivers/acpi/acpi_amba.c
new file mode 100644
index 000..4f0366a
--- /dev/null
+++ b/drivers/acpi/acpi_amba.c
@@ -0,0 +1,157 @@
+/*
+ * ACPI support for AMBA bus type.
+ *
+ * Copyright (C) 2015, Advanced Micro Devices, Inc.
+ * Authors: Huang Rui
+ * Wang Hongcheng
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "internal.h"
+
+ACPI_MODULE_NAME("amba");
+
+/**
+ * acpi_create_amba_device - Create AMBA device for ACPI device node.
+ * @adev: ACPI device node to create an AMBA device.
+ * @periphid: AMBA device periphid.
+ * @fixed_rate: Clock frequency.
+ * @pdata: Platform data specific to the device.
+ *
+ * Check if the given @adev can be represented as an AMBA device and, if
+ * that's the case, create and register an AMBA device, populate its
+ * common resources and returns a pointer to it. Otherwise, return
+ * %NULL or ERR_PTR() on error.
+ *
+ * Name of the AMBA device will be the same as @adev's.
+ */
+struct amba_device *acpi_create_amba_device(struct acpi_device *adev,
+ unsigned int periphid,
+ unsigned long fixed_rate,
+ void *pdata)
+{
+ struct amba_device *amba_dev = NULL;
+ struct device *parent;
+ struct acpi_device *acpi_parent;
+ struct resource_entry *rentry;
+ struct list_head resource_list;
+ struct resource *resource = NULL;
+ int count, ret = 0;
+ unsigned int i;
+ unsigned int irq[AMBA_NR_IRQS];
+ struct clk *clk = ERR_PTR(-ENODEV);
+
+ /*
+* If the ACPI node already has a physical device attached,
+* skip it.
+*/
+ if (adev->physical_node_count)
+ return NULL;
+
+ INIT_LIST_HEAD(_list);
+ count = acpi_dev_get_resources(adev, _list, NULL, NULL);
+ if (count <= 0)
+ return NULL;
+
+ resource = kzalloc(sizeof(*resource), GFP_KERNEL);
+ if (!resource)
+ goto resource_alloc_err;
+
+ count = 0;
+ list_for_each_entry(rentry, _list, node) {
+ if (resource_type(rentry->res) == IORESOURCE_IRQ) {
+ irq[count] = rentry->res->start;
+ count++;
+ }
+ /*
+* there is only one io memory resource entry
+* at current AMBA device design
+*/
+ if (resource_type(rentry->res) | IORESOURCE_MEM)
+ memcpy(resource, rentry->res, sizeof(struct resource));
+ }
+
+ amba_dev = amba_device_alloc(dev_name(>dev),
+resource->start,
+resource_size(resource));
+
+ if (!amba_dev)
+ goto amba_alloc_err;
+
+ amba_dev->dev.coherent_dma_mask = acpi_dma_supported(adev) ?
DMA_BIT_MASK(64) : 0;
+ amba_dev->dev.platform_data = pdata;
+ amba_dev->dev.fwnode = acpi_fwnode_handle(adev);
+
+ /*
+* If the ACPI node has a parent and that parent has a
+* physical device attached to it, that physical device should
+* be the parent of the AMBA device we are about to create.
+*/
+ parent = NULL;
+ acpi_parent = adev->parent;
+ if (acpi_parent) {
+ struct acpi_device_physical_node *entry;
+ struct list_head *list;
+
+ mutex_lock(_parent->physical_node_lock);
+
[PATCH v3 2/2] arm64: ftrace: fix the comments for ftrace_modify_code
There is no need to worry about module and __init text disappearing
case, because that ftrace has a module notifier that is called when
a module is being unloaded and before the text goes away and this
code grabs the ftrace_lock mutex and removes the module functions
from the ftrace list, such that it will no longer do any
modifications to that module's text, the update to make functions
be traced or not is done under the ftrace_lock mutex as well.
And by now, __init section codes should not been modified
by ftrace, because it is black listed in recordmcount.c and
ignored by ftrace.
Suggested-by: Steven Rostedt
Signed-off-by: Li Bin
---
arch/arm64/kernel/ftrace.c | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
index 9669b33..8f7005b 100644
--- a/arch/arm64/kernel/ftrace.c
+++ b/arch/arm64/kernel/ftrace.c
@@ -29,12 +29,11 @@ static int ftrace_modify_code(unsigned long pc, u32 old,
u32 new,
/*
* Note:
-* Due to modules and __init, code can disappear and change,
-* we need to protect against faulting as well as code changing.
-* We do this by aarch64_insn_*() which use the probe_kernel_*().
-*
-* No lock is held here because all the modifications are run
-* through stop_machine().
+* We are paranoid about modifying text, as if a bug were to happen, it
+* could cause us to read or write to someplace that could cause harm.
+* Carefully read and modify the code with aarch64_insn_*() which uses
+* probe_kernel_*(), and make sure what we read is what we expected it
+* to be before modifying it.
*/
if (validate) {
if (aarch64_insn_read((void *)pc, ))
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 9/9] dmaengine: Kconfig: rename ARCH_HI3xxx to ARCH_HI36xx
Hi Arnd, On 2015/12/3 17:41, Arnd Bergmann wrote: > On Thursday 03 December 2015 10:49:37 Jiancheng Xue wrote: >> Rename ARCH_HI3xxx to ARCH_HI36xx. >> >> Signed-off-by: Jiancheng Xue > > Maybe just change it to 'depends on ARCH_HISI'? That would make it > possible to merge the change independently. OK. Agree with you! > > This also needs a better changelog text. OK. I'll try to make the changelog text more detailed. > > Arnd > > . > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/9] Documentation: Add ivrs_acpihid kernel parameter description
From: Wan Zongshun Add ivrs_acpihid kernel parameter description, like ivrs_acpihid[00:14.5]=AMD0020:0. Signed-off-by: Wan Zongshun --- Documentation/kernel-parameters.txt | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 742f69d..5c364c6 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1680,6 +1680,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted. PCI device 00:14.0 write the parameter as: ivrs_hpet[0]=00:14.0 + ivrs_acpihid[HW,X86_64] + Provide an override to the ACPI-HID:UID<->DEVICE-ID + mapping provided in the IVRS ACPI table. For + example, to map UART-HID:UID AMD0020:0 to + PCI device 00:14.5 write the parameter as: + ivrs_acpihid[00:14.5]=AMD0020:0 + js= [HW,JOY] Analog joystick See Documentation/input/joystick.txt. -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/9] clk: hi3519: add dt-binding document and header file
Hi Arnd, On 2015/12/3 17:44, Arnd Bergmann wrote: > On Thursday 03 December 2015 10:39:24 Jiancheng Xue wrote: >> +#ifndef __DTS_HI3519_CLOCK_H >> +#define __DTS_HI3519_CLOCK_H > > Please try to avoid adding headers like this if you can at all. > > I might ask you to merge the header file in one merge window > otherwise and submit the platform code one kernel later, as they > tendn to cause us needless dependencies otherwise. > Sorry. In v1, Rob suggested putting binding doc and header files in a separate patch. The clock driver indeed depends on the header. I will put the header and the clock driver in a patch, and keep the binding doc in another patch. > >> +/* fixed rate */ >> +#define HI3519_FIXED_400M 1 >> +#define HI3519_FIXED_200M 2 >> +#define HI3519_FIXED_125M 3 >> +#define HI3519_FIXED_150M 4 >> +#define HI3519_FIXED_75M 5 >> +#define HI3519_FIXED_300M 6 >> +#define HI3519_FIXED_50M 7 >> +#define HI3519_FIXED_24M 8 >> +#define HI3519_FIXED_3M9 >> + >> +/* mux clocks */ >> +#define HI3519_FMC_MUX 32 >> +#define HI3519_I2C_MUX 33 >> +#define HI3519_UART_MUX34 >> +#define HI3519_SYSAXI_MUX 35 >> + >> +/*fixed factor clocks*/ >> +#define HI3519_SYSAPB_CLK 64 >> + >> +/* gate clocks */ >> +#define HI3519_FMC_CLK 129 >> +#define HI3519_UART0_CLK 153 >> +#define HI3519_UART1_CLK 154 >> +#define HI3519_UART2_CLK 155 >> +#define HI3519_UART3_CLK 156 >> +#define HI3519_UART4_CLK 157 > > Where do those numbers come from? They are not consecutive, so it sounds > like they are directly from the data sheet and won't be needed in the driver. > If that's true, just use the numbers directly, as you do for everything > else. The numbers are defined by myself, not directly from the data sheet. Some numbers are reserved for device nodes which will be added later. So they are not consecutive now. > >> +#define HI3519_NR_CLKS 256 >> +#define HI3519_NR_RSTS 256 >> > These seem to not be needed at all. These are used in drivers/clk/hisilicon/clk-hi3519.c. > > Arnd > > . > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] arm64: ftrace: fix the comments for ftrace_modify_code
on 2015/12/4 10:50, Steven Rostedt wrote:
> On Fri, 4 Dec 2015 10:18:39 +0800
> Li Bin wrote:
>
>> There is no need to worry about module text disappearing case,
>> because that ftrace has a module notifier that is called when
>> a module is being unloaded and before the text goes away, and this
>> code grabs the ftrace_lock mutex and removes the module functions
>> from the ftrace list, such that it will no longer do any
>> modifications to that module's text.
>> The update to make functions be traced or not is done under the
>> ftrace_lock mutex as well.
>>
>> Signed-off-by: Li Bin
>> ---
>> arch/arm64/kernel/ftrace.c |5 +
>> 1 files changed, 1 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
>> index 9669b33..ee91c0c 100644
>> --- a/arch/arm64/kernel/ftrace.c
>> +++ b/arch/arm64/kernel/ftrace.c
>> @@ -29,12 +29,9 @@ static int ftrace_modify_code(unsigned long pc, u32 old,
>> u32 new,
>>
>> /*
>> * Note:
>> - * Due to modules and __init, code can disappear and change,
>> + * Due to __init, code can disappear and change,
> Init code should not be modified either because it is black listed in
> recordmcount.c.
>
> I say just change the comment to be something like:
>
> We are paranoid about modifying text, as if a bug were to happen, it
> could cause us to read or write to someplace that could cause harm.
> Carefully read and modify the code with aarch64_insn_*() which uses
> probe_kernel_*(), and make sure what we read is what we expected it to
> be before modifying it.
Ok, I will modify it.
Thanks,
Li Bin
> -- Steve
>
>
>> * we need to protect against faulting as well as code changing.
>> * We do this by aarch64_insn_*() which use the probe_kernel_*().
>> - *
>> - * No lock is held here because all the modifications are run
>> - * through stop_machine().
>> */
>> if (validate) {
>> if (aarch64_insn_read((void *)pc, ))
>
> .
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] ARM: shmobile: r8a7791: enable to use thermal-zone
From: Kuninori Morimoto
This patch enables to use thermal-zone on r8a7791.
This thermal sensor can measure temperature from -4 to 125000,
but over 117000 can be critical on this chip.
Thus, default critical temperature is now set as 115000 (this driver
is using 5000 steps) (Current critical temperature is using it as
9, but there is no big reason about it)
And it doesn't check thermal zone periodically (same as current
behavior). You can exchange it by modifing polling-delay[-passive]
property.
You can set trip temp if your kernel has CONFIG_THERMAL_WRITABLE_TRIPS,
but you need to take care to use it, since it will call
orderly_poweroff() it it reached to the value.
echo $temp > /sys/class/thermal/thermal_zone0/trip_point_0_temp
Signed-off-by: Kuninori Morimoto
---
arch/arm/boot/dts/r8a7791.dtsi | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 1487d92..2fff856 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -69,6 +69,25 @@
};
};
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+
+ thermal-sensors = <>;
+
+ trips {
+ cpu-crit {
+ temperature = <115>;
+ hysteresis = <0>;
+ type= "critical";
+ };
+ };
+ cooling-maps {
+ };
+ };
+ };
+
gic: interrupt-controller@f1001000 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
@@ -185,12 +204,15 @@
power-domains = <_clocks>;
};
- thermal@e61f {
- compatible = "renesas,thermal-r8a7791", "renesas,rcar-thermal";
+ thermal: thermal@e61f {
+ compatible ="renesas,thermal-r8a7791",
+ "renesas,rcar-thermal-gen2",
+ "renesas,rcar-thermal";
reg = <0 0xe61f 0 0x14>, <0 0xe61f0100 0 0x38>;
interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
clocks = <_clks R8A7791_CLK_THERMAL>;
power-domains = <_clocks>;
+ #thermal-sensor-cells = <0>;
};
timer {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] ARM: shmobile: r8a7790: enable to use thermal-zone
From: Kuninori Morimoto
This patch enables to use thermal-zone on r8a7790.
This thermal sensor can measure temperature from -4 to 125000,
but over 117000 can be critical on this chip.
Thus, default critical temperature is now set as 115000 (this driver
is using 5000 steps) (Current critical temperature is using it as
9, but there is no big reason about it)
And it doesn't check thermal zone periodically (same as current
behavior). You can exchange it by modifing polling-delay[-passive]
property.
You can set trip temp if your kernel has CONFIG_THERMAL_WRITABLE_TRIPS,
but you need to take care to use it, since it will call
orderly_poweroff() it it reached to the value.
echo $temp > /sys/class/thermal/thermal_zone0/trip_point_0_temp
Signed-off-by: Kuninori Morimoto
---
arch/arm/boot/dts/r8a7790.dtsi | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 6cfd0dc..bbbc3cd 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -112,6 +112,25 @@
};
};
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+
+ thermal-sensors = <>;
+
+ trips {
+ cpu-crit {
+ temperature = <115>;
+ hysteresis = <0>;
+ type= "critical";
+ };
+ };
+ cooling-maps {
+ };
+ };
+ };
+
gic: interrupt-controller@f1001000 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
@@ -202,12 +221,15 @@
power-domains = <_clocks>;
};
- thermal@e61f {
- compatible = "renesas,thermal-r8a7790", "renesas,rcar-thermal";
+ thermal: thermal@e61f {
+ compatible ="renesas,thermal-r8a7790",
+ "renesas,rcar-thermal-gen2",
+ "renesas,rcar-thermal";
reg = <0 0xe61f 0 0x14>, <0 0xe61f0100 0 0x38>;
interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
clocks = <_clks R8A7790_CLK_THERMAL>;
power-domains = <_clocks>;
+ #thermal-sensor-cells = <0>;
};
timer {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] thermal: rcar: enable to use thermal-zone on DT
From: Kuninori Morimoto
This patch enables to use thermal-zone on DT if it was call as
"renesas,rcar-thermal-gen2".
Previous style is still supported by "renesas,rcar-thermal".
Signed-off-by: Kuninori Morimoto
---
.../devicetree/bindings/thermal/rcar-thermal.txt | 37 +-
drivers/thermal/rcar_thermal.c | 45 +++---
2 files changed, 74 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
index 332e625..904f204 100644
--- a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
@@ -1,8 +1,9 @@
* Renesas R-Car Thermal
Required properties:
-- compatible : "renesas,thermal-", "renesas,rcar-thermal"
- as fallback.
+- compatible : "renesas,thermal-",
+ "renesas,rcar-thermal-gen2" (with thermal-zone) or
+ "renesas,rcar-thermal" (without thermal-zone) as
fallback.
Examples with soctypes are:
- "renesas,thermal-r8a73a4" (R-Mobile APE6)
- "renesas,thermal-r8a7779" (R-Car H1)
@@ -36,3 +37,35 @@ thermal@e61f {
0xe61f0300 0x38>;
interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
};
+
+Example (with thermal-zone):
+
+thermal-zones {
+ cpu_thermal: cpu-thermal {
+ polling-delay-passive = <1000>;
+ polling-delay = <5000>;
+
+ thermal-sensors = <>;
+
+ trips {
+ cpu-crit {
+ temperature = <115>;
+ hysteresis = <0>;
+ type= "critical";
+ };
+ };
+ cooling-maps {
+ };
+ };
+};
+
+thermal: thermal@e61f {
+ compatible ="renesas,thermal-r8a7790",
+ "renesas,rcar-thermal-gen2",
+ "renesas,rcar-thermal";
+ reg = <0 0xe61f 0 0x14>, <0 0xe61f0100 0 0x38>;
+ interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <_clks R8A7790_CLK_THERMAL>;
+ power-domains = <_clocks>;
+ #thermal-sensor-cells = <0>;
+};
diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
index 96707a6..9c9e38b 100644
--- a/drivers/thermal/rcar_thermal.c
+++ b/drivers/thermal/rcar_thermal.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -81,8 +82,10 @@ struct rcar_thermal_priv {
# define rcar_force_update_temp(priv) 0
#endif
+#define USE_OF_THERMAL 1
static const struct of_device_id rcar_thermal_dt_ids[] = {
{ .compatible = "renesas,rcar-thermal", },
+ { .compatible = "renesas,rcar-thermal-gen2", .data = (void
*)USE_OF_THERMAL },
{},
};
MODULE_DEVICE_TABLE(of, rcar_thermal_dt_ids);
@@ -206,17 +209,35 @@ err_out_unlock:
return ret;
}
-static int rcar_thermal_get_temp(struct thermal_zone_device *zone, int *temp)
+static int rcar_thermal_get_current_temp(struct rcar_thermal_priv *priv)
{
- struct rcar_thermal_priv *priv = rcar_zone_to_priv(zone);
+ int temp;
if (!rcar_has_irq_support(priv) || rcar_force_update_temp(priv))
rcar_thermal_update_temp(priv);
mutex_lock(>lock);
- *temp = MCELSIUS((priv->ctemp * 5) - 65);
+ temp = MCELSIUS((priv->ctemp * 5) - 65);
mutex_unlock(>lock);
+ return temp;
+}
+
+static int rcar_thermal_of_get_temp(void *data, int *temp)
+{
+ struct rcar_thermal_priv *priv = data;
+
+ *temp = rcar_thermal_get_current_temp(priv);
+
+ return 0;
+}
+
+static int rcar_thermal_get_temp(struct thermal_zone_device *zone, int *temp)
+{
+ struct rcar_thermal_priv *priv = rcar_zone_to_priv(zone);
+
+ *temp = rcar_thermal_get_current_temp(priv);
+
return 0;
}
@@ -276,6 +297,10 @@ static int rcar_thermal_notify(struct thermal_zone_device
*zone,
return 0;
}
+static const struct thermal_zone_of_device_ops rcar_thermal_zone_of_ops = {
+ .get_temp = rcar_thermal_of_get_temp,
+};
+
static struct thermal_zone_device_ops rcar_thermal_zone_ops = {
.get_temp = rcar_thermal_get_temp,
.get_trip_type = rcar_thermal_get_trip_type,
@@ -308,11 +333,11 @@ static void rcar_thermal_work(struct work_struct *work)
priv = container_of(work, struct rcar_thermal_priv, work.work);
- rcar_thermal_get_temp(priv->zone, );
+ cctemp = rcar_thermal_get_current_temp(priv);
rcar_thermal_update_temp(priv);
rcar_thermal_irq_enable(priv);
- rcar_thermal_get_temp(priv->zone, );
+ nctemp = rcar_thermal_get_current_temp(priv);
if (nctemp != cctemp)
[PATCH 1/4] thermal: rcar: move rcar_thermal_dt_ids to upside
From: Kuninori Morimoto
This patch is prepare for of-thermal support.
Signed-off-by: Kuninori Morimoto
---
drivers/thermal/rcar_thermal.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
index 13d01ed..96707a6 100644
--- a/drivers/thermal/rcar_thermal.c
+++ b/drivers/thermal/rcar_thermal.c
@@ -81,6 +81,12 @@ struct rcar_thermal_priv {
# define rcar_force_update_temp(priv) 0
#endif
+static const struct of_device_id rcar_thermal_dt_ids[] = {
+ { .compatible = "renesas,rcar-thermal", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, rcar_thermal_dt_ids);
+
/*
* basic functions
*/
@@ -484,12 +490,6 @@ error_unregister:
return ret;
}
-static const struct of_device_id rcar_thermal_dt_ids[] = {
- { .compatible = "renesas,rcar-thermal", },
- {},
-};
-MODULE_DEVICE_TABLE(of, rcar_thermal_dt_ids);
-
static struct platform_driver rcar_thermal_driver = {
.driver = {
.name = "rcar_thermal",
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] enable to use thermal-zone on r8a7790/1
Hi These are enable to use thermal-zone on r8a7790/r8a7791. The rcar thermal driver can use of-thermal style zone by this patch, but it still keeping current style too. You can select trip temp by DT if you use of-thermal style (this patch). If not, it will use fixed trip temp. Kuninori Morimoto (4): thermal: rcar: move rcar_thermal_dt_ids to upside thermal: rcar: enable to use thermal-zone on DT ARM: shmobile: r8a7790: enable to use thermal-zone ARM: shmobile: r8a7791: enable to use thermal-zone Documentation/devicetree/bindings/thermal/rcar-thermal.txt | 37 +++-- arch/arm/boot/dts/r8a7790.dtsi | 26 -- arch/arm/boot/dts/r8a7791.dtsi | 26 -- drivers/thermal/rcar_thermal.c | 57 + 4 files changed, 128 insertions(+), 18 deletions(-) Best regards --- Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] arm64: ftrace: stop using kstop_machine to enable/disable tracing
On Fri, 4 Dec 2015 10:18:38 +0800
Li Bin wrote:
> For ftrace on arm64, kstop_machine which is hugely disruptive
> to a running system is not needed to convert nops to ftrace calls
> or back, because that to be modified instrucions, that NOP, B or BL,
> are all safe instructions which called "concurrent modification
> and execution of instructions", that can be executed by one
> thread of execution as they are being modified by another thread
> of execution without requiring explicit synchronization.
>
> Signed-off-by: Li Bin
> ---
> arch/arm64/kernel/ftrace.c |5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
> index c851be7..9669b33 100644
> --- a/arch/arm64/kernel/ftrace.c
> +++ b/arch/arm64/kernel/ftrace.c
> @@ -93,6 +93,11 @@ int ftrace_make_nop(struct module *mod, struct dyn_ftrace
> *rec,
> return ftrace_modify_code(pc, old, new, true);
> }
>
> +void arch_ftrace_update_code(int command)
> +{
> + ftrace_modify_all_code(command);
Hmm, I wonder why I haven't done this for powerpc. I probably should.
Anyway,
Reviewed-by: Steven Rostedt
If it is indeed safe not to do any special handling.
-- Steve
> +}
> +
> int __init ftrace_dyn_arch_init(void)
> {
> return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] time: verify time values in adjtimex ADJ_SETOFFSET to avoid overflow
Make sure the tv_usec makes sense. We might multiply them later which can
cause an overflow and undefined behavior.
Signed-off-by: Sasha Levin
---
kernel/time/timekeeping.c |4
1 file changed, 4 insertions(+)
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index d563c19..aa3c1c2 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1987,6 +1987,10 @@ int do_adjtimex(struct timex *txc)
if (txc->modes & ADJ_SETOFFSET) {
struct timespec delta;
+
+ if (txc->time.tv_usec >= USEC_PER_SEC || txc->time.tv_usec <=
-USEC_PER_SEC)
+ return -EINVAL;
+
delta.tv_sec = txc->time.tv_sec;
delta.tv_nsec = txc->time.tv_usec;
if (!(txc->modes & ADJ_NANO))
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] bitops.h: correctly handle rol32 with 0 byte shift
ROL on a 32 bit integer with a shift of 32 or more is undefined and the
result is arch-dependent. Avoid this by handling the trivial case of
roling by 0 correctly.
The trivial solution of checking if shift is 0 breaks gcc's detection
of this code as a ROL instruction, which is unacceptable.
This bug was reported and fixed in GCC
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57157):
The standard rotate idiom,
(x << n) | (x >> (32 - n))
is recognized by gcc (for concreteness, I discuss only the case that x
is an uint32_t here).
However, this is portable C only for n in the range 0 < n < 32. For n
== 0, we get x >> 32 which gives undefined behaviour according to the
C standard (6.5.7, Bitwise shift operators). To portably support n ==
0, one has to write the rotate as something like
(x << n) | (x >> ((-n) & 31))
And this is apparently not recognized by gcc.
Note that this is broken on older GCCs and will result in slower ROL.
Acked-by: Linus Torvalds
Signed-off-by: Sasha Levin
---
include/linux/bitops.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index 2b8ed12..defeaac 100644
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -107,7 +107,7 @@ static inline __u64 ror64(__u64 word, unsigned int shift)
*/
static inline __u32 rol32(__u32 word, unsigned int shift)
{
- return (word << shift) | (word >> (32 - shift));
+ return (word << shift) | (word >> ((-shift) & 31));
}
/**
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] storvsc: add more logging for error and warning messages
Thanks Joe.
I'll send out another patch.
> -Original Message-
> From: Joe Perches [mailto:j...@perches.com]
> Sent: Thursday, December 3, 2015 6:28 PM
> To: Long Li ; KY Srinivasan ;
> Haiyang Zhang ; James E.J. Bottomley
>
> Cc: de...@linuxdriverproject.org; linux-s...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH] storvsc: add more logging for error and warning
> messages
>
> On Thu, 2015-12-03 at 19:47 -0800, Long Li wrote:
> > Introduce a logging level for storvsc to log certain error/warning
> > messages. Those messages are helpful in some environments, e.g.
> > Microsoft Azure, for customer support and troubleshooting purposes.
> []
> > diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> []
> > +static inline bool do_logging(int level) {
> > + return (logging_level >= level) ? true : false;
>
> The ternary is not necessary
>
> return logging_level >= level;
>
> is enough
>
> > +}
> > +
> > +
> > struct vmscsi_win8_extension {
> > /*
> > * The following were added in Windows 8 @@ -1183,7 +1198,7 @@
> > static void storvsc_command_completion(struct storvsc_cmd_request
> > *cmd_request)
> >
> > scmnd->result = vm_srb->scsi_status;
> >
> > - if (scmnd->result) {
> > + if (scmnd->result && do_logging(STORVSC_LOGGING_ERROR)) {
> > if (scsi_normalize_sense(scmnd->sense_buffer,
> > SCSI_SENSE_BUFFERSIZE, _hdr))
> > scsi_print_sense_hdr(scmnd->device, "storvsc",
>
> Is it appropriate to make this scsi_normalize_sense call conditional on
> do_logging here?
>
> > @@ -1239,12 +1254,25 @@ static void storvsc_on_io_completion(struct
> hv_device *device,
> > stor_pkt->vm_srb.sense_info_length =
> > vstor_packet->vm_srb.sense_info_length;
> >
> > + if (vstor_packet->vm_srb.scsi_status != 0 ||
> > + vstor_packet->vm_srb.srb_status != SRB_STATUS_SUCCESS)
> > + if (do_logging(STORVSC_LOGGING_WARN))
> > + dev_warn(>device,
> > + "cmd 0x%x scsi status 0x%x srb status
> 0x%x\n",
> > + stor_pkt->vm_srb.cdb[0],
> > + vstor_packet->vm_srb.scsi_status,
> > + vstor_packet->vm_srb.srb_status);
>
> It might make some sense to use another macro indirection like
>
> #define svc_log_warn(dev, level, fmt, ...)\
> do { \
> if (do_logging(STORSVC_LOGGING_##level) \
> dev_warn(&(dev)->device, fmt, ##__VA_ARGS__); \
> } while (0)
>
> So a use could be:
>
> if (vstore_packet...)
> svc_log_warn(device, WARN, ...);
>
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] nvdimm: do not show pfn_seed for non pmem regions
On Tue, Dec 1, 2015 at 10:39 PM, Dmitry V. Krivenok wrote: > This simple change hides pfn_seed attribute for non pmem > regions because they don't support pfn anyway. > > Signed-off-by: Dmitry V. Krivenok > --- Looks good I'll queue it for 4.5. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] nvdimm: improve diagnosibility of namespaces
On Tue, Dec 1, 2015 at 1:48 PM, Dmitry V. Krivenok wrote: > In order to bind namespace to the driver user must first > set all mandatory attributes in the following order: > - uuid > - size > - sector_size (for blk namespace only) > > If the order is wrong, then user either won't be able to set > the attribute or bind the namespace. > > This simple patch improves diagnosibility of common operations > with namespaces by printing some details about the error > instead of failing silently. > > Below are examples of error messages (assuming dyndbg is > enabled for nvdimms): > > [/]# echo 4194304 > /sys/bus/nd/devices/region5/namespace5.0/size > [ 288.372612] nd namespace5.0: __size_store: uuid not set > [ 288.374839] nd namespace5.0: size_store: 40 fail (-6) > sh: write error: No such device or address > [/]# > > [/]# echo namespace5.0 > /sys/bus/nd/drivers/nd_blk/bind > [ 554.671648] nd_blk namespace5.0: nvdimm_namespace_common_probe: sector > size not set > [ 554.674688] ndbus1: nd_blk.probe(namespace5.0) = -19 > sh: write error: No such device > [/]# > > Signed-off-by: Dmitry V. Krivenok Looks good I'll queue it for 4.5. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] arm64: ftrace: fix the comments for ftrace_modify_code
On Fri, 4 Dec 2015 10:18:39 +0800
Li Bin wrote:
> There is no need to worry about module text disappearing case,
> because that ftrace has a module notifier that is called when
> a module is being unloaded and before the text goes away, and this
> code grabs the ftrace_lock mutex and removes the module functions
> from the ftrace list, such that it will no longer do any
> modifications to that module's text.
> The update to make functions be traced or not is done under the
> ftrace_lock mutex as well.
>
> Signed-off-by: Li Bin
> ---
> arch/arm64/kernel/ftrace.c |5 +
> 1 files changed, 1 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
> index 9669b33..ee91c0c 100644
> --- a/arch/arm64/kernel/ftrace.c
> +++ b/arch/arm64/kernel/ftrace.c
> @@ -29,12 +29,9 @@ static int ftrace_modify_code(unsigned long pc, u32 old,
> u32 new,
>
> /*
>* Note:
> - * Due to modules and __init, code can disappear and change,
> + * Due to __init, code can disappear and change,
Init code should not be modified either because it is black listed in
recordmcount.c.
I say just change the comment to be something like:
We are paranoid about modifying text, as if a bug were to happen, it
could cause us to read or write to someplace that could cause harm.
Carefully read and modify the code with aarch64_insn_*() which uses
probe_kernel_*(), and make sure what we read is what we expected it to
be before modifying it.
-- Steve
>* we need to protect against faulting as well as code changing.
>* We do this by aarch64_insn_*() which use the probe_kernel_*().
> - *
> - * No lock is held here because all the modifications are run
> - * through stop_machine().
>*/
> if (validate) {
> if (aarch64_insn_read((void *)pc, ))
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb: xhci-mtk: fix AHB bus hang up caused by roothubs polling
when ip fail to enter sleep mode, register access protection will
be disabed, at the same time if all clocks are disabled, access
register will hang up AHB bus.
the common case causes ip sleep fail is that after all ports enter
U3 but before ip enters sleep mode, a port receives a resume
signal('K'). this will happens when such as clicks mouse to try to
do remote wakeup to stop system enter suspend.
so stop polling roothubs to avoid access xHCI register on bus
suspend, and restart it when bus resume.
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mtk.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index c9ab6a4..38635fb 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -696,9 +696,24 @@ static int xhci_mtk_remove(struct platform_device *dev)
}
#ifdef CONFIG_PM_SLEEP
+/*
+ * if ip sleep fail, and all clocks are disabled, access register will hang
+ * AHB bus, so stop poll roothubs to avoid regs access on bus suspend.
+ * and no need to check whether ip sleep fail or not; this will cause SPM to
+ * wakeup system immediately after system suspend complete if ip sleep
+ * fail, it is what we wanted.
+ */
static int xhci_mtk_suspend(struct device *dev)
{
struct xhci_hcd_mtk *mtk = dev_get_drvdata(dev);
+ struct usb_hcd *hcd = mtk->hcd;
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+
+ xhci_dbg(xhci, "%s: stop port polling\n", __func__);
+ clear_bit(HCD_FLAG_POLL_RH, >flags);
+ del_timer_sync(>rh_timer);
+ clear_bit(HCD_FLAG_POLL_RH, >shared_hcd->flags);
+ del_timer_sync(>shared_hcd->rh_timer);
xhci_mtk_host_disable(mtk);
xhci_mtk_phy_power_off(mtk);
@@ -710,11 +725,19 @@ static int xhci_mtk_suspend(struct device *dev)
static int xhci_mtk_resume(struct device *dev)
{
struct xhci_hcd_mtk *mtk = dev_get_drvdata(dev);
+ struct usb_hcd *hcd = mtk->hcd;
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
usb_wakeup_disable(mtk);
xhci_mtk_clks_enable(mtk);
xhci_mtk_phy_power_on(mtk);
xhci_mtk_host_enable(mtk);
+
+ xhci_dbg(xhci, "%s: restart port polling\n", __func__);
+ set_bit(HCD_FLAG_POLL_RH, >flags);
+ usb_hcd_poll_rh_status(hcd);
+ set_bit(HCD_FLAG_POLL_RH, >shared_hcd->flags);
+ usb_hcd_poll_rh_status(xhci->shared_hcd);
return 0;
}
--
1.8.1.1.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] Add __GFP_ZERO to alloc_cpumask_var_node() if ptr is zero
On Fri, 04 Dec 2015 12:05:12 +1030 Rusty Russell wrote: > This is clever, but I would advise against such subtle code. We will > never be able to remove this code once it is in. > > Would suggest making the non-CPUMASK_OFFSTACK stubs write garbage into > the cpumasks instead, iff !(flags & __GFP_ZERO). > > I actually thought of the same thing, but thought it was a bit harsh. If others think that's a better solution, then I'll submit a patch to do that. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/9] ARM: dts: add dts files for hi3519-demb board
Hi Arnd,
Thank you very much for all your comments.
On 2015/12/3 17:36, Arnd Bergmann wrote:
> On Thursday 03 December 2015 10:44:28 Jiancheng Xue wrote:
>
>> +
>> +/dts-v1/;
>> +#include "hi3519.dtsi"
>> +
>> +/ {
>> +model = "HiSilicon HI3519 DEMO Board";
>> +compatible = "hisilicon,hi3519";
>> +
>> +chosen {
>> +bootargs = "mem=64M console=ttyAMA0,115200 early_printk \
>> +root=/dev/mtdblock2 rootfstype=jffs2 \
>> +mtdparts=hi_sfc:1M(boot),4M(kernel),11M(rootfs)";
>> +};
>
> Most of the arguments should be dropped and replaced with the respective
> DT properties in this file:
>
> mem: /memory (you have that already, but the size seems wrong)
> console: /chosen/stdout-path
> early_printk: just drop this, maybe use "earlycon")
> root: this one is fine
> rootfstype: should not be needed
> mtdparts: use nodes below the MTD device
>
This chosen node is just for debug. The real parameters will be set at boot
stage.
I will drop it.
>> +
>> +#include "skeleton.dtsi"
>> +#include
>> +/ {
>> +aliases {
>> +serial0 =
>> +};
>
> Move this into the .dts file.
OK. Thank you.
>
>> +
>> +uart0: uart@1210 {
>
> rename to serial@1210
OK.
>
>> +dual_timer1: dual_timer@12001000 {
>> +compatible = "arm,sp804", "arm,primecell";
>> +interrupts = <0 66 4>, <0 67 4>;
>> +reg = <0x12001000 0x1000>;
>> +clocks = < HI3519_FIXED_3M>;
>> +status = "disable";
>> +};
>
> rename to timer@12001000
OK.
>
>> +sysctrl: system-controller@1202 {
>> +compatible = "hisilicon,sysctrl";
>> +reg = <0x1202 0x1000>;
>> +reboot-offset = <0x4>;
>> +};
>
> Is this one identical to the one in hip04?
>
> If not, pick a new unique compatible string
Yes. It's compatible with the one in hip04.
>
>> +
>> +crg: crg@1201 {
>> +compatible = "hisilicon,hi3519-crg";
>
>
> what is a "crg"? Is there a standard name for these?
The "crg" means Clock and Reset Generator. It's a block which supplies clock
and reset signals for other modules in the chip. I used "hi3519-clock"
in last version patch. Rob Herring suggested that it's better to use
"hi3519-crg"
as the compatible string if it's a whole block.
what about writing like this？
crg: clock-reset-controller@1201 {
compatible = "hisilicon,hi3519-crg";
}
>
> Arnd
>
> .
>
Jiancheng
.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] storvsc: add more logging for error and warning messages
On Thu, 2015-12-03 at 19:47 -0800, Long Li wrote:
> Introduce a logging level for storvsc to log certain error/warning
> messages. Those messages are helpful in some environments, e.g.
> Microsoft Azure, for customer support and troubleshooting purposes.
[]
> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
[]
> +static inline bool do_logging(int level)
> +{
> + return (logging_level >= level) ? true : false;
The ternary is not necessary
return logging_level >= level;
is enough
> +}
> +
> +
> struct vmscsi_win8_extension {
> /*
> * The following were added in Windows 8
> @@ -1183,7 +1198,7 @@ static void storvsc_command_completion(struct
> storvsc_cmd_request *cmd_request)
>
> scmnd->result = vm_srb->scsi_status;
>
> - if (scmnd->result) {
> + if (scmnd->result && do_logging(STORVSC_LOGGING_ERROR)) {
> if (scsi_normalize_sense(scmnd->sense_buffer,
> SCSI_SENSE_BUFFERSIZE, _hdr))
> scsi_print_sense_hdr(scmnd->device, "storvsc",
Is it appropriate to make this scsi_normalize_sense call
conditional on do_logging here?
> @@ -1239,12 +1254,25 @@ static void storvsc_on_io_completion(struct hv_device
> *device,
> stor_pkt->vm_srb.sense_info_length =
> vstor_packet->vm_srb.sense_info_length;
>
> + if (vstor_packet->vm_srb.scsi_status != 0 ||
> + vstor_packet->vm_srb.srb_status != SRB_STATUS_SUCCESS)
> + if (do_logging(STORVSC_LOGGING_WARN))
> + dev_warn(>device,
> + "cmd 0x%x scsi status 0x%x srb status 0x%x\n",
> + stor_pkt->vm_srb.cdb[0],
> + vstor_packet->vm_srb.scsi_status,
> + vstor_packet->vm_srb.srb_status);
It might make some sense to use another macro indirection like
#define svc_log_warn(dev, level, fmt, ...) \
do {\
if (do_logging(STORSVC_LOGGING_##level) \
dev_warn(&(dev)->device, fmt, ##__VA_ARGS__); \
} while (0)
So a use could be:
if (vstore_packet...)
svc_log_warn(device, WARN, ...);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/12] clk: samsung: exynos5420: add cpu clock configuration data and instantiate cpu clock
On 03.12.2015 19:30, Ben Gamari wrote:
> Krzysztof Kozlowski writes:
>
>> On 03.12.2015 06:19, Ben Gamari wrote:
>>> From: Thomas Abraham
>>>
>>> With the addition of the new Samsung specific cpu-clock type, the
>>> arm clock can be represented as a cpu-clock type. Add the CPU clock
>>> configuration data and instantiate the CPU clock type for Exynos5420.
>>>
>>> Changes by Bartlomiej:
>>> - split Exynos5420 support from the original patches
>>> - moved E5420_[EGL,KFC]_DIV0() macros to clk-exynos5420.c
>>>
>>> Changes by Ben Gamari:
>>> - Rebased
>>
>> If only rebasing then you should retain the Lukasz's review tag. He
>> doesn't have to review it again, right? :)
>
> Yep, very true.
>
>>> +static const struct exynos_cpuclk_cfg_data exynos5420_eglclk_d[]
>>> __initconst = {
>>> + { 180, E5420_EGL_DIV0(3, 7, 7, 4), },
>>> + { 170, E5420_EGL_DIV0(3, 7, 7, 3), },
>>> + { 160, E5420_EGL_DIV0(3, 7, 7, 3), },
>>> + { 150, E5420_EGL_DIV0(3, 7, 7, 3), },
>>> + { 140, E5420_EGL_DIV0(3, 7, 7, 3), },
>>> + { 130, E5420_EGL_DIV0(3, 7, 7, 2), },
>>> + { 120, E5420_EGL_DIV0(3, 7, 7, 2), },
>>> + { 110, E5420_EGL_DIV0(3, 7, 7, 2), },
>>> + { 100, E5420_EGL_DIV0(3, 6, 6, 2), },
>>> + { 90, E5420_EGL_DIV0(3, 6, 6, 2), },
>>> + { 80, E5420_EGL_DIV0(3, 5, 5, 2), },
>>> + { 70, E5420_EGL_DIV0(3, 5, 5, 2), },
>>> + { 60, E5420_EGL_DIV0(3, 4, 4, 2), },
>>> + { 50, E5420_EGL_DIV0(3, 3, 3, 2), },
>>> + { 40, E5420_EGL_DIV0(3, 3, 3, 2), },
>>> + { 30, E5420_EGL_DIV0(3, 3, 3, 2), },
>>> + { 20, E5420_EGL_DIV0(3, 3, 3, 2), },
>>> + { 0 },
>>
>> The vendor code (Galaxy S5 with Exynos5422) sets pclk_dbg divider to 7.
>> In the same time APLL divider is only 1.
>>
>> For the ACLK divider (of KFC below) the vendor sets 3, not 2.
>>
>> The values also don't match the Exynos5420 from Note 3.
>>
>> The Exynos5800 apparently has values more similar to 5422.
>>
>> The question is: for which exact model this is? We can of course choose
>> the safest values here but probably these would be with the highest
>> dividers?
>>
> I'm afraid I can't comment here. Thomas, perhaps you could offer some
> insight?
Actually I found your patch #5 adding support for 5800 with the values
more like matching 5422. So actually the difference should be between
5420 and 5422. The Exynos5420 mainline boards are:
- Peach Pit - chromeos tree could be a good vendor reference,
- Arndale Octa,
- SMDK5420.
For the last two I don't know where to get the vendor reference.
Unfortunately sometimes the particular values (supported frequencies and
clock dividers) differ for one SoC between products but we don't support
the ASV here.
Overall probably this means that we should not care about such details,
except maybe the difference between 5420 and 5422? (where 5422=5800)
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 3/3] vhost_net: basic polling support
On 12/02/2015 08:36 PM, Michael S. Tsirkin wrote: > On Wed, Dec 02, 2015 at 01:04:03PM +0800, Jason Wang wrote: >> >> On 12/01/2015 10:43 PM, Michael S. Tsirkin wrote: >>> On Tue, Dec 01, 2015 at 01:17:49PM +0800, Jason Wang wrote: On 11/30/2015 06:44 PM, Michael S. Tsirkin wrote: > On Wed, Nov 25, 2015 at 03:11:29PM +0800, Jason Wang wrote: >>> This patch tries to poll for new added tx buffer or socket receive >>> queue for a while at the end of tx/rx processing. The maximum time >>> spent on polling were specified through a new kind of vring ioctl. >>> >>> Signed-off-by: Jason Wang > One further enhancement would be to actually poll > the underlying device. This should be reasonably > straight-forward with macvtap (especially in the > passthrough mode). > > Yes, it is. I have some patches to do this by replacing skb_queue_empty() with sk_busy_loop() but for tap. >>> We probably don't want to do this unconditionally, though. >>> Tests does not show any improvement but some regression. >>> Did you add code to call sk_mark_napi_id on tap then? >>> sk_busy_loop won't do anything useful without. >> Yes I did. Probably something wrong elsewhere. > Is this for guest-to-guest? Nope. Like you said below, since it requires NAPI so it was external host to guest. > the patch to do napi > for tap is still not upstream due to minor performance > regression. Want me to repost it? Sure, I've played this a little bit in the past too. > Maybe it's better to test macvtap. >>> Same thing ... >>> > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/2] arm64: stop using kstop_machine for ftrace
v2: Based on the comments from Will and Steve, 1. Modify the commit message 2. Fix the misleading comments for ftrace_modify_code Link: https://lkml.org/lkml/2015/12/3/422 Li Bin (2): arm64: ftrace: stop using kstop_machine to enable/disable tracing arm64: ftrace: fix the comments for ftrace_modify_code arch/arm64/kernel/ftrace.c | 10 ++ 1 files changed, 6 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] arm64: ftrace: stop using kstop_machine to enable/disable tracing
For ftrace on arm64, kstop_machine which is hugely disruptive
to a running system is not needed to convert nops to ftrace calls
or back, because that to be modified instrucions, that NOP, B or BL,
are all safe instructions which called "concurrent modification
and execution of instructions", that can be executed by one
thread of execution as they are being modified by another thread
of execution without requiring explicit synchronization.
Signed-off-by: Li Bin
---
arch/arm64/kernel/ftrace.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
index c851be7..9669b33 100644
--- a/arch/arm64/kernel/ftrace.c
+++ b/arch/arm64/kernel/ftrace.c
@@ -93,6 +93,11 @@ int ftrace_make_nop(struct module *mod, struct dyn_ftrace
*rec,
return ftrace_modify_code(pc, old, new, true);
}
+void arch_ftrace_update_code(int command)
+{
+ ftrace_modify_all_code(command);
+}
+
int __init ftrace_dyn_arch_init(void)
{
return 0;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] arm64: ftrace: fix the comments for ftrace_modify_code
There is no need to worry about module text disappearing case,
because that ftrace has a module notifier that is called when
a module is being unloaded and before the text goes away, and this
code grabs the ftrace_lock mutex and removes the module functions
from the ftrace list, such that it will no longer do any
modifications to that module's text.
The update to make functions be traced or not is done under the
ftrace_lock mutex as well.
Signed-off-by: Li Bin
---
arch/arm64/kernel/ftrace.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
index 9669b33..ee91c0c 100644
--- a/arch/arm64/kernel/ftrace.c
+++ b/arch/arm64/kernel/ftrace.c
@@ -29,12 +29,9 @@ static int ftrace_modify_code(unsigned long pc, u32 old, u32
new,
/*
* Note:
-* Due to modules and __init, code can disappear and change,
+* Due to __init, code can disappear and change,
* we need to protect against faulting as well as code changing.
* We do this by aarch64_insn_*() which use the probe_kernel_*().
-*
-* No lock is held here because all the modifications are run
-* through stop_machine().
*/
if (validate) {
if (aarch64_insn_read((void *)pc, ))
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] storvsc: add more logging for error and warning messages
Introduce a logging level for storvsc to log certain error/warning messages.
Those messages are helpful in some environments, e.g. Microsoft Azure, for
customer support and troubleshooting purposes.
Signed-off-by: Long Li
---
drivers/scsi/storvsc_drv.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 40c43ae..afa1647 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -164,6 +164,21 @@ static int sense_buffer_size =
PRE_WIN8_STORVSC_SENSE_BUFFER_SIZE;
*/
static int vmstor_proto_version;
+#define STORVSC_LOGGING_NONE 0
+#define STORVSC_LOGGING_ERROR 1
+#define STORVSC_LOGGING_WARN 2
+
+static int logging_level = STORVSC_LOGGING_ERROR;
+module_param(logging_level, int, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(logging_level,
+ "Logging level, 0 - None, 1 - Error (default), 2 - Warning.");
+
+static inline bool do_logging(int level)
+{
+ return (logging_level >= level) ? true : false;
+}
+
+
struct vmscsi_win8_extension {
/*
* The following were added in Windows 8
@@ -1183,7 +1198,7 @@ static void storvsc_command_completion(struct
storvsc_cmd_request *cmd_request)
scmnd->result = vm_srb->scsi_status;
- if (scmnd->result) {
+ if (scmnd->result && do_logging(STORVSC_LOGGING_ERROR)) {
if (scsi_normalize_sense(scmnd->sense_buffer,
SCSI_SENSE_BUFFERSIZE, _hdr))
scsi_print_sense_hdr(scmnd->device, "storvsc",
@@ -1239,12 +1254,25 @@ static void storvsc_on_io_completion(struct hv_device
*device,
stor_pkt->vm_srb.sense_info_length =
vstor_packet->vm_srb.sense_info_length;
+ if (vstor_packet->vm_srb.scsi_status != 0 ||
+ vstor_packet->vm_srb.srb_status != SRB_STATUS_SUCCESS)
+ if (do_logging(STORVSC_LOGGING_WARN))
+ dev_warn(>device,
+ "cmd 0x%x scsi status 0x%x srb status 0x%x\n",
+ stor_pkt->vm_srb.cdb[0],
+ vstor_packet->vm_srb.scsi_status,
+ vstor_packet->vm_srb.srb_status);
if ((vstor_packet->vm_srb.scsi_status & 0xFF) == 0x02) {
/* CHECK_CONDITION */
if (vstor_packet->vm_srb.srb_status &
SRB_STATUS_AUTOSENSE_VALID) {
/* autosense data available */
+ if (do_logging(STORVSC_LOGGING_WARN))
+ dev_warn(>device,
+ "stor pkt %p autosense data valid - len
%d\n",
+ request,
+ vstor_packet->vm_srb.sense_info_length);
memcpy(request->cmd->sense_buffer,
vstor_packet->vm_srb.sense_data,
--
1.8.5.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] KVM: VMX: fix read/write sizes of VMCS fields
On 2015/12/3 23:11, Paolo Bonzini wrote:
In theory this should have broken EPT on 32-bit kernels (due to
reading the high part of natural-width field GUEST_CR3). Not sure
if no one noticed or the processor behaves differently from the
documentation.
It seems we will check the success of vmcs_write but not vmcs_read.
Shouldn't check the vmcs_read?
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/vmx.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index c39737ff0581..b1af1e48070b 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -4868,7 +4868,7 @@ static void vmx_vcpu_reset(struct kvm_vcpu *vcpu, bool
init_event)
seg_setup(VCPU_SREG_CS);
vmcs_write16(GUEST_CS_SELECTOR, 0xf000);
- vmcs_write32(GUEST_CS_BASE, 0x);
+ vmcs_writel(GUEST_CS_BASE, 0xul);
seg_setup(VCPU_SREG_DS);
seg_setup(VCPU_SREG_ES);
@@ -4904,7 +4904,7 @@ static void vmx_vcpu_reset(struct kvm_vcpu *vcpu, bool
init_event)
vmcs_write32(GUEST_ACTIVITY_STATE, GUEST_ACTIVITY_ACTIVE);
vmcs_write32(GUEST_INTERRUPTIBILITY_INFO, 0);
- vmcs_write32(GUEST_PENDING_DBG_EXCEPTIONS, 0);
+ vmcs_writel(GUEST_PENDING_DBG_EXCEPTIONS, 0);
setup_msrs(vmx);
@@ -7893,7 +7893,7 @@ static void dump_vmcs(void)
u32 pin_based_exec_ctrl = vmcs_read32(PIN_BASED_VM_EXEC_CONTROL);
u32 secondary_exec_control = 0;
unsigned long cr4 = vmcs_readl(GUEST_CR4);
- u64 efer = vmcs_readl(GUEST_IA32_EFER);
+ u64 efer = vmcs_read64(GUEST_IA32_EFER);
int i, n;
if (cpu_has_secondary_exec_ctrls())
@@ -10159,7 +10159,7 @@ static void prepare_vmcs12(struct kvm_vcpu *vcpu,
struct vmcs12 *vmcs12,
* Additionally, restore L2's PDPTR to vmcs12.
*/
if (enable_ept) {
- vmcs12->guest_cr3 = vmcs_read64(GUEST_CR3);
+ vmcs12->guest_cr3 = vmcs_readl(GUEST_CR3);
vmcs12->guest_pdptr0 = vmcs_read64(GUEST_PDPTR0);
vmcs12->guest_pdptr1 = vmcs_read64(GUEST_PDPTR1);
vmcs12->guest_pdptr2 = vmcs_read64(GUEST_PDPTR2);
--
best regards
yang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND,PATCH] phy: phy-mt65xx-usb3: improve HS eye diagram
calibrate HS slew rate and switch 100uA current to SSUSB
to improve HS eye diagram of HQA test.
Signed-off-by: Chunfeng Yun
---
drivers/phy/phy-mt65xx-usb3.c | 99 +--
1 file changed, 96 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
index dc480d3..9069162 100644
--- a/drivers/phy/phy-mt65xx-usb3.c
+++ b/drivers/phy/phy-mt65xx-usb3.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -27,6 +28,7 @@
* relative to USB3_SIF2_BASE base address
*/
#define SSUSB_SIFSLV_SPLLC 0x
+#define SSUSB_SIFSLV_U2FREQ0x0100
/* offsets of sub-segment in each port registers */
#define SSUSB_SIFSLV_U2PHY_COM_BASE0x
@@ -41,6 +43,7 @@
#define PA2_RG_SIF_U2PLL_FORCE_EN BIT(18)
#define U3P_USBPHYACR5 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0014)
+#define PA5_RG_U2_HSTX_SRCAL_ENBIT(15)
#define PA5_RG_U2_HSTX_SRCTRL GENMASK(14, 12)
#define PA5_RG_U2_HSTX_SRCTRL_VAL(x) ((0x7 & (x)) << 12)
#define PA5_RG_U2_HS_100U_U3_ENBIT(11)
@@ -113,6 +116,24 @@
#define XC3_RG_U3_XTAL_RX_PWD BIT(9)
#define XC3_RG_U3_FRC_XTAL_RX_PWD BIT(8)
+#define U3P_U2FREQ_FMCR0 (SSUSB_SIFSLV_U2FREQ + 0x00)
+#define P2F_RG_MONCLK_SEL GENMASK(27, 26)
+#define P2F_RG_MONCLK_SEL_VAL(x) ((0x3 & (x)) << 26)
+#define P2F_RG_FREQDET_EN BIT(24)
+#define P2F_RG_CYCLECNTGENMASK(23, 0)
+#define P2F_RG_CYCLECNT_VAL(x) ((P2F_RG_CYCLECNT) & (x))
+
+#define U3P_U2FREQ_VALUE (SSUSB_SIFSLV_U2FREQ + 0x0c)
+
+#define U3P_U2FREQ_FMMONR1 (SSUSB_SIFSLV_U2FREQ + 0x10)
+#define P2F_USB_FM_VALID BIT(0)
+#define P2F_RG_FRCK_EN BIT(8)
+
+#define U3P_REF_CLK26 /* MHZ */
+#define U3P_SLEW_RATE_COEF 28
+#define U3P_SR_COEF_DIVISOR1000
+#define U3P_FM_DET_CYCLE_CNT 1024
+
struct mt65xx_phy_instance {
struct phy *phy;
void __iomem *port_base;
@@ -128,6 +149,77 @@ struct mt65xx_u3phy {
int nphys;
};
+static void hs_slew_rate_calibrate(struct mt65xx_u3phy *u3phy,
+ struct mt65xx_phy_instance *instance)
+{
+ void __iomem *sif_base = u3phy->sif_base;
+ int calibration_val;
+ int fm_out;
+ u32 tmp;
+
+ /* enable USB ring oscillator */
+ tmp = readl(instance->port_base + U3P_USBPHYACR5);
+ tmp |= PA5_RG_U2_HSTX_SRCAL_EN;
+ writel(tmp, instance->port_base + U3P_USBPHYACR5);
+ udelay(1);
+
+ /*enable free run clock */
+ tmp = readl(sif_base + U3P_U2FREQ_FMMONR1);
+ tmp |= P2F_RG_FRCK_EN;
+ writel(tmp, sif_base + U3P_U2FREQ_FMMONR1);
+
+ /* set cycle count as 1024, and select u2 channel */
+ tmp = readl(sif_base + U3P_U2FREQ_FMCR0);
+ tmp &= ~(P2F_RG_CYCLECNT | P2F_RG_MONCLK_SEL);
+ tmp |= P2F_RG_CYCLECNT_VAL(U3P_FM_DET_CYCLE_CNT);
+ tmp |= P2F_RG_MONCLK_SEL_VAL(instance->index);
+ writel(tmp, sif_base + U3P_U2FREQ_FMCR0);
+
+ /* enable frequency meter */
+ tmp = readl(sif_base + U3P_U2FREQ_FMCR0);
+ tmp |= P2F_RG_FREQDET_EN;
+ writel(tmp, sif_base + U3P_U2FREQ_FMCR0);
+
+ /* ignore return value */
+ readl_poll_timeout(sif_base + U3P_U2FREQ_FMMONR1, tmp,
+ (tmp & P2F_USB_FM_VALID), 10, 200);
+
+ fm_out = readl(sif_base + U3P_U2FREQ_VALUE);
+
+ /* disable frequency meter */
+ tmp = readl(sif_base + U3P_U2FREQ_FMCR0);
+ tmp &= ~P2F_RG_FREQDET_EN;
+ writel(tmp, sif_base + U3P_U2FREQ_FMCR0);
+
+ /*disable free run clock */
+ tmp = readl(sif_base + U3P_U2FREQ_FMMONR1);
+ tmp &= ~P2F_RG_FRCK_EN;
+ writel(tmp, sif_base + U3P_U2FREQ_FMMONR1);
+
+ if (fm_out) {
+ /* ( 1024 / FM_OUT ) x reference clock frequency x 0.028 */
+ tmp = U3P_FM_DET_CYCLE_CNT * U3P_REF_CLK * U3P_SLEW_RATE_COEF;
+ tmp /= fm_out;
+ calibration_val = DIV_ROUND_CLOSEST(tmp, U3P_SR_COEF_DIVISOR);
+ } else {
+ /* if FM detection fail, set default value */
+ calibration_val = 4;
+ }
+ dev_dbg(u3phy->dev, "phy:%d, fm_out:%d, calib:%d\n",
+ instance->index, fm_out, calibration_val);
+
+ /* set HS slew rate */
+ tmp = readl(instance->port_base + U3P_USBPHYACR5);
+ tmp &= ~PA5_RG_U2_HSTX_SRCTRL;
+ tmp |= PA5_RG_U2_HSTX_SRCTRL_VAL(calibration_val);
+ writel(tmp, instance->port_base + U3P_USBPHYACR5);
+
+ /* disable USB ring oscillator */
+ tmp = readl(instance->port_base + U3P_USBPHYACR5);
+ tmp &= ~PA5_RG_U2_HSTX_SRCAL_EN;
+ writel(tmp, instance->port_base + U3P_USBPHYACR5);
+}
+
static void phy_instance_init(struct mt65xx_u3phy *u3phy,
struct mt65xx_phy_instance *instance)
{
@@ -226,9 +318,9 @@ static void phy_instance_power_on(struct mt65xx_u3phy
*u3phy,
tmp |=
[RESEND,PATCH] phy: phy-mt65xx-usb3: fix test fail of HS receiver sensitivity
when use the default value 8 of RG_USB20_SQTH, the HS receiver sensitivity test of HQA will fail, set it as 2 to fix up the issue. Signed-off-by: Chunfeng Yun --- drivers/phy/phy-mt65xx-usb3.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c index f30b28b..dc480d3 100644 --- a/drivers/phy/phy-mt65xx-usb3.c +++ b/drivers/phy/phy-mt65xx-usb3.c @@ -49,6 +49,8 @@ #define PA6_RG_U2_ISO_EN BIT(31) #define PA6_RG_U2_BC11_SW_EN BIT(23) #define PA6_RG_U2_OTG_VBUSCMP_EN BIT(20) +#define PA6_RG_U2_SQTH GENMASK(3, 0) +#define PA6_RG_U2_SQTH_VAL(x) (0xf & (x)) #define U3P_U2PHYACR4 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0020) #define P2C_RG_USB20_GPIO_CTL BIT(9) @@ -165,9 +167,10 @@ static void phy_instance_init(struct mt65xx_u3phy *u3phy, writel(tmp, port_base + U3P_U2PHYDTM0); } - /* DP/DM BC1.1 path Disable */ tmp = readl(port_base + U3P_USBPHYACR6); - tmp &= ~PA6_RG_U2_BC11_SW_EN; + tmp &= ~PA6_RG_U2_BC11_SW_EN; /* DP/DM BC1.1 path Disable */ + tmp &= ~PA6_RG_U2_SQTH; + tmp |= PA6_RG_U2_SQTH_VAL(2); writel(tmp, port_base + U3P_USBPHYACR6); tmp = readl(port_base + U3P_U3PHYA_DA_REG0); -- 1.8.1.1.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] sched/fair: Move hot load_avg into its own cacheline
On Thu, 2015-12-03 at 14:34 -0500, Waiman Long wrote: > On 12/02/2015 11:32 PM, Mike Galbraith wrote: > > Is that with the box booted skew_tick=1? > I haven't tried that kernel parameter. I will try it to see if it can > improve the situation. BTW, will there be other undesirable side effects > of using this other than the increased power consumption as said in the > kernel-parameters.txt file? Not that are known. I kinda doubt you'd notice the power, but you should see a notable performance boost. Who knows, with a big enough farm of busy big boxen, it may save power by needing fewer of them. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND,PATCH] phy: core: Get a refcount to phy in devm_of_phy_get_by_index()
On driver detach, devm_phy_release() will put a refcount to
the phy, so gets a refconut to it before return.
Signed-off-by: Chunfeng Yun
---
drivers/phy/phy-core.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index fc48fac..8c7f27d 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -636,8 +636,9 @@ EXPORT_SYMBOL_GPL(devm_of_phy_get);
* @np: node containing the phy
* @index: index of the phy
*
- * Gets the phy using _of_phy_get(), and associates a device with it using
- * devres. On driver detach, release function is invoked on the devres data,
+ * Gets the phy using _of_phy_get(), then gets a refcount to it,
+ * and associates a device with it using devres. On driver detach,
+ * release function is invoked on the devres data,
* then, devres data is freed.
*
*/
@@ -651,13 +652,21 @@ struct phy *devm_of_phy_get_by_index(struct device *dev,
struct device_node *np,
return ERR_PTR(-ENOMEM);
phy = _of_phy_get(np, index);
- if (!IS_ERR(phy)) {
- *ptr = phy;
- devres_add(dev, ptr);
- } else {
+ if (IS_ERR(phy)) {
devres_free(ptr);
+ return phy;
}
+ if (!try_module_get(phy->ops->owner)) {
+ devres_free(ptr);
+ return ERR_PTR(-EPROBE_DEFER);
+ }
+
+ get_device(>dev);
+
+ *ptr = phy;
+ devres_add(dev, ptr);
+
return phy;
}
EXPORT_SYMBOL_GPL(devm_of_phy_get_by_index);
--
1.8.1.1.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rtc: fix overflow and incorrect calculation in rtc_time64_to_tm
On 12/03/2015 08:55 PM, Alexandre Belloni wrote: > On 03/12/2015 at 19:12:24 -0500, Sasha Levin wrote : >> > At some point after humans go extinct and robots cotrol the world, dividing >> > he time64_t by 86400 to extract the days will overflow a 32bit integer, >> > leading to incorrect conversion into rtc_time in rtc_time64_to_tm(). >> > > And at that time, the robots won't care about 32bit platforms :) One can only hope... :) I'll resend. Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 1/1] x86/platform/iosf_mbi: Remove duplicate definitions
>-Original Message- >From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- >ow...@vger.kernel.org] On Behalf Of Andy Shevchenko >Sent: Wednesday, November 25, 2015 10:33 PM >To: Thomas Gleixner >Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; linux- >p...@vger.kernel.org; Ingo Molnar ; Peter Anvin >; Wolfram Sang ; Zhang, Rui >; Eduardo Valentin ; Kweh, Hock >Leong >Subject: Re: [PATCH v2 1/1] x86/platform/iosf_mbi: Remove duplicate definitions > >On Wed, 2015-11-25 at 15:20 +0100, Thomas Gleixner wrote: >> On Wed, 11 Nov 2015, Andy Shevchenko wrote: >> >> > The read and write opcodes are global for all units on SoC and even >> across >> > Intel SoCs. Remove duplication of corresponding constants. At the >> same time >> > convert all current users. >> > >> > No functional change. >> > >> > Cc: Thomas Gleixner >> > Cc: Ingo Molnar >> > Cc: Peter Anvin >> > Cc: Wolfram Sang >> > Cc: Zhang Rui >> > Cc: Eduardo Valentin >> > Cc: Hock Leong Kweh > >Eduardo, Rui, can you provide your ACKs or comments about the patch? > Rui, I have reviewed the change on drivers/thermal/intel_quark_dts_thermal.c. Yes, I gave my ACK here.
Re: [RFC][PATCH] Add __GFP_ZERO to alloc_cpumask_var_node() if ptr is zero
Steven Rostedt writes:
> Xunlei Pang reported a bug in the scheduler code when
> CONFIG_CPUMASK_OFFSTACK is set, several of the cpumasks used by the
> root domains can contain garbage. The code does the following:
>
> memset(rd, 0, sizeof(*rd));
>
> if (!alloc_cpumask_var(>span, GFP_KERNEL))
> goto out;
> if (!alloc_cpumask_var(>online, GFP_KERNEL))
> goto free_span;
> if (!alloc_cpumask_var(>dlo_mask, GFP_KERNEL))
> goto free_online;
> if (!alloc_cpumask_var(>rto_mask, GFP_KERNEL))
> goto free_dlo_mask;
>
> When CONFIG_CPUMASK_OFFSTACK is not defined, the four cpumasks are part
> of the 'rd' structure, and the memset() will zero them all out. But
> when CONFIG_CPUMASK_OFFSTACK is enabled, those cpumasks are no longer
> set by the memset() but are allocated independently. That allocation
> may contain garbage.
>
> In order to make alloc_cpumask_var() and friends behave the same with
> respect to being zero or not whether or not CONFIG_CPUMASK_OFFSTACK is
> defined, a check is made to the contents of the mask pointer. If the
> contents of the mask pointer is zero, it is assumed that the value was
> zeroed out before and __GFP_ZERO is added to the flags for allocation
> to make the returned cpumasks already zeroed.
>
> Calls to alloc_cpumask_var() are not done in performance critical
> paths, and even if they are, zeroing them out shouldn't add much
> overhead to it. The up side to this change is that we remove subtle
> bugs when enabling CONFIG_CPUMASK_OFFSTACK with cpumask logic that
> worked fined when that config was not enabled.
This is clever, but I would advise against such subtle code. We will
never be able to remove this code once it is in.
Would suggest making the non-CPUMASK_OFFSTACK stubs write garbage into
the cpumasks instead, iff !(flags & __GFP_ZERO).
Cheers,
Rusty.
>
> Signed-off-by: Steven Rostedt
> ---
> diff --git a/lib/cpumask.c b/lib/cpumask.c
> index 5a70f6196f57..c0d68752a8b9 100644
> --- a/lib/cpumask.c
> +++ b/lib/cpumask.c
> @@ -60,6 +60,19 @@ int cpumask_any_but(const struct cpumask *mask, unsigned
> int cpu)
> */
> bool alloc_cpumask_var_node(cpumask_var_t *mask, gfp_t flags, int node)
> {
> + /*
> + * When CONFIG_CPUMASK_OFFSTACK is not set, the cpumask may
> + * be zeroed by a memset of the structure that contains the
> + * mask. But if CONFIG_CPUMASK_OFFSTACK is then enabled,
> + * the mask may end up containing garbage. By checking
> + * if the pointer of the mask is already zero, we can assume
> + * that the mask itself should be allocated to contain all
> + * zeros as well. This will prevent subtle bugs by the
> + * inconsistency of the config being set or not.
> + */
> + if ((long)*mask == 0)
> + flags |= __GFP_ZERO;
> +
> *mask = kmalloc_node(cpumask_size(), flags, node);
>
> #ifdef CONFIG_DEBUG_PER_CPU_MAPS
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] livepatch: Cleanup module page permission changes
Jiri Kosina writes:
> On Thu, 3 Dec 2015, Josh Poimboeuf wrote:
>
>> Calling set_memory_rw() and set_memory_ro() for every iteration of the
>> loop in klp_write_object_relocations() is messy, inefficient, and
>> error-prone.
>>
>> Change all the read-only pages to read-write before the loop and convert
>> them back to read-only again afterwards.
>>
>> Suggested-by: Miroslav Benes
>> Signed-off-by: Josh Poimboeuf
>> ---
>> Based on the following branches:
>> - git://git.kernel.org/pub/scm/linux/kernel/git/jikos/livepatching.git
>> for-4.5/core
>> - git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git modules-next
>>
>> - v4: rebase onto Chris's sympos changes
>> - v3: use new module_{disable,enable}_ro() functions (in linux-next)
>
> Rusty,
>
> how would you like to handle this cross-tree dependency?
>
> My proposals:
>
> (1) I pull your 'modules-next' branch, apply this patch on top, and wait
> for your merge with Linus and send merge request afterwards
Hmm, that's always a bit icky.
> (2) If you are okay with rebasing your tree (seems like this is
> ocassionally happening), how about you prepare a branch that'd have
> just b3212ec77 ("module: keep percpu symbols in module's symtab") on
> top of some common base, I merge it, and the cross-dependency is gone
I don't like to rebase, but I am *always* happy to give patches away :)
> (3) I cherry-pick b3212ec77 ("module: keep percpu symbols in
> module's symtab") from your tree, and apply this on top. git will
> handle duplicate commits when Linus merges both just fine
That's pretty ugly.
> (4) I sign this patch off and you merge it
>
> (4) seems really outside the regular process. (1) is really tricky wrt.
> coordination of timing during the merge window. I'd prefer (2) (more
> git-ish way of doing things, but would require you rebasing your tree) or
> eventually (3) (git will handle this with grace).
The last won't work anyway, since I'd need to grab stuff from your
tree...
> What do you think?
Please cherry-pick my whole module-next tree. They have my SOB already.
You can push them to Linus along with your livepatch stuff at your
convenience for the merge window.
Once you've done that, I'll rebase modules-next down to nothing. If
something else comes in, I'll either add it there or toss it to you,
depending on whether it conflicts or not.
Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
transakce~
Ahoj, napiste mi na e-mailovou adresu pro podrobnosti o vzájemne spoluprace. chn.chn.j...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rtc: fix overflow and incorrect calculation in rtc_time64_to_tm
On 03/12/2015 at 19:12:24 -0500, Sasha Levin wrote :
> At some point after humans go extinct and robots cotrol the world, dividing
> he time64_t by 86400 to extract the days will overflow a 32bit integer,
> leading to incorrect conversion into rtc_time in rtc_time64_to_tm().
>
And at that time, the robots won't care about 32bit platforms :)
> Signed-off-by: Sasha Levin
> ---
> drivers/rtc/rtc-lib.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/rtc/rtc-lib.c b/drivers/rtc/rtc-lib.c
> index e6bfb9c..459cd4d 100644
> --- a/drivers/rtc/rtc-lib.c
> +++ b/drivers/rtc/rtc-lib.c
> @@ -54,11 +54,11 @@ void rtc_time64_to_tm(time64_t time, struct rtc_time *tm)
> {
> unsigned int month, year;
> unsigned long secs;
> - int days;
> + time64_t days;
>
> /* time must be positive */
> days = div_s64(time, 86400);
> - secs = time - (unsigned int) days * 86400;
> + secs = time - days * 86400;
>
> /* day of the week, 1970-01-01 was a Thursday */
> tm->tm_wday = (days + 4) % 7;
> --
> 1.7.10.4
>
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [lkp] [mm, page_alloc] d0164adc89: -100.0% fsmark.app_overhead
Mel Gorman writes:
> On Thu, Dec 03, 2015 at 04:46:53PM +0800, Huang, Ying wrote:
>> Mel Gorman writes:
>>
>> > On Wed, Dec 02, 2015 at 03:15:29PM +0100, Michal Hocko wrote:
>> >> > > I didn't mention this allocation failure because I am not sure it is
>> >> > > really related.
>> >> > >
>> >> >
>> >> > I'm fairly sure it is. The failure is an allocation site that cannot
>> >> > sleep but did not specify __GFP_HIGH.
>> >>
>> >> yeah but this was the case even before your patch. As the caller used
>> >> GFP_ATOMIC then it got __GFP_ATOMIC after your patch so it still
>> >> managed to do ALLOC_HARDER. I would agree if this was an explicit
>> >> GFP_NOWAIT. Unless I am missing something your patch hasn't changed the
>> >> behavior for this particular allocation.
>> >>
>> >
>> > You're right. I think it's this hunk that is the problem.
>> >
>> > @@ -1186,7 +1186,7 @@ static struct request *blk_mq_map_request(struct
>> > request_queue *q,
>> > ctx = blk_mq_get_ctx(q);
>> > hctx = q->mq_ops->map_queue(q, ctx->cpu);
>> > blk_mq_set_alloc_data(_data, q,
>> > - __GFP_WAIT|GFP_ATOMIC, false, ctx, hctx);
>> > + __GFP_WAIT|__GFP_HIGH, false, ctx, hctx);
>> > rq = __blk_mq_alloc_request(_data, rw);
>> > ctx = alloc_data.ctx;
>> > hctx = alloc_data.hctx;
>> >
>> > This specific path at this patch is not waking kswapd any more when it
>> > should. A series of allocations there could hit the watermarks and never
>> > wake
>> > kswapd and then be followed by an atomic allocation failure that woke
>> > kswapd.
>> >
>> > This bug gets fixed later by the commit 71baba4b92dc ("mm, page_alloc:
>> > rename __GFP_WAIT to __GFP_RECLAIM") so it's not a bug in the current
>> > kernel. However, it happens to break bisection and would be caught if each
>> > individual commit was tested.
>> >
>> > Your __GFP_HIGH patch is still fine although not the direct fix for this
>> > specific problem. Commit 71baba4b92dc is.
>> >
>> > Ying, does the page allocation failure messages happen when the whole
>> > series is applied? i.e. is 4.4-rc3 ok?
>>
>> There are allocation errors for 4.4-rc3 too. dmesg is attached.
>>
>
> What is the result of the __GFP_HIGH patch to give it access to
> reserves?
Applied Michal's patch on v4.4-rc3 and tested again, now there is no
page allocation failure.
Best Regards,
Huang, Ying
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SoCFPGA ethernet broken
On Fri, Dec 04, 2015 at 02:10:50AM +0100, Andrew Lunn wrote:
> > > FWIW: My initial patch to address the failure worked with the original
> > > DTB.
> >
> > Can I ask what patch are you referring to? I was sidetracked for a while
> > on this issue, but I still see it failing as of v4.4-rc3. I'll try to
> > get back to debugging this.
>
> Hi Dinh
>
> There are two different patches:
>
> https://lkml.org/lkml/2015/10/16/669
>
> and
>
> https://www.mail-archive.com/netdev@vger.kernel.org/msg83183.html
>
> Although the first one works, it keeps searching up and up and up, so
> you could in theory put the phy properties a lot higher than the MAC.
>
> The second patch restricts where it looks for the phy properties to
> only the MAC. But it does not work. We would like to understand why it
> does not work.
Hi Dinh
Please could you run this patch and let us know what it outputs.
Thanks
Andrew
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index cf6312fafea5..d7ddc0bb0e7f 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -339,9 +340,19 @@ static int ksz9021_config_init(struct phy_device *phydev)
{
const struct device *dev = >dev;
const struct device_node *of_node = dev->of_node;
+ const struct device *dev_walker;
- if (!of_node && dev->parent->of_node)
- of_node = dev->parent->of_node;
+ dev_info(dev, "dev->parent: %s\n", dev_name(dev->parent));
+ dev_info(dev, "phydev->attached_dev->dev: %s\n",
dev_name(>attached_dev->dev));
+
+ dev_walker = >dev;
+ do {
+ of_node = dev_walker->of_node;
+ dev_info(dev, "walking: %s %p\n",
+dev_name(dev_walker), of_node);
+ dev_walker = dev_walker->parent;
+
+ } while (!of_node && dev_walker);
if (of_node) {
ksz9021_load_values_from_of(phydev, of_node,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] clear file privilege bits when mmap writing
> On Dec 2, 2015, at 16:03, Kees Cook wrote: > > Normally, when a user can modify a file that has setuid or setgid bits, > those bits are cleared when they are not the file owner or a member > of the group. This is enforced when using write and truncate but not > when writing to a shared mmap on the file. This could allow the file > writer to gain privileges by changing a binary without losing the > setuid/setgid/caps bits. > > Changing the bits requires holding inode->i_mutex, so it cannot be done > during the page fault (due to mmap_sem being held during the fault). > Instead, clear the bits if PROT_WRITE is being used at mmap time. > > Signed-off-by: Kees Cook > Cc: sta...@vger.kernel.org > — is this means mprotect() sys call also need add this check? mprotect() can change to PROT_WRITE, then it can write to a read only map again , also a secure hole here . Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 8/9] drm/vc4: Add support for async pageflips.
Daniel Stone writes: > Hi, > > On 1 December 2015 at 20:35, Eric Anholt wrote: >> An async pageflip stores the modeset to be done and executes it once >> the BOs are ready to be displayed. This gets us about 3x performance >> in full screen rendering with pageflipping. > > Looks good, but you're missing a preclose callback to reap dead events, a la: > https://git.collabora.com/cgit/user/daniels/linux.git/commit/?h=wip/4.4.x/rockchip-drm-fixes=d14f21bcd7e7a1b9ca129c411a9da9c911037965 > > (and parent commit to wire that through to core DRM preclose) We've already got a preclose callback that reaps crtc->event -- see vc4_cancel_page_flip(). signature.asc Description: PGP signature
Re: [PATCH] rtc: fix overflow and incorrect calculation in rtc_time64_to_tm
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system] Hi Sasha, [auto build test ERROR on abelloni/rtc-next] [also build test ERROR on v4.4-rc3 next-20151202] url: https://github.com/0day-ci/linux/commits/Sasha-Levin/rtc-fix-overflow-and-incorrect-calculation-in-rtc_time64_to_tm/20151204-081508 base: https://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git rtc-next config: arm-prima2_defconfig (attached as .config) 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 # save the attached .config to linux build tree make.cross ARCH=arm All errors (new ones prefixed by >>): drivers/built-in.o: In function `rtc_time64_to_tm': >> drivers/rtc/rtc-lib.c:64: undefined reference to `__aeabi_ldivmod' drivers/rtc/rtc-lib.c:66: undefined reference to `__aeabi_ldivmod' vim +64 drivers/rtc/rtc-lib.c c58411e9 Alessandro Zummo 2006-03-27 58 c2c11ae4 pang.xunlei 2014-11-18 59/* time must be positive */ c2c11ae4 pang.xunlei 2014-11-18 60days = div_s64(time, 86400); ee9fd0e8 Sasha Levin 2015-12-03 61secs = time - days * 86400; c58411e9 Alessandro Zummo 2006-03-27 62 c58411e9 Alessandro Zummo 2006-03-27 63/* day of the week, 1970-01-01 was a Thursday */ c58411e9 Alessandro Zummo 2006-03-27 @64tm->tm_wday = (days + 4) % 7; c58411e9 Alessandro Zummo 2006-03-27 65 c58411e9 Alessandro Zummo 2006-03-27 66year = 1970 + days / 365; c58411e9 Alessandro Zummo 2006-03-27 67days -= (year - 1970) * 365 :: The code at line 64 was first introduced by commit :: c58411e95d7f5062dedd1a3064af4d359da1e633 [PATCH] RTC Subsystem: library functions :: TO: Alessandro Zummo :: CC: Linus Torvalds --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
Re: [PATCH] rtc: fix overflow and incorrect calculation in rtc_time64_to_tm
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system] Hi Sasha, [auto build test ERROR on abelloni/rtc-next] [also build test ERROR on v4.4-rc3 next-20151202] url: https://github.com/0day-ci/linux/commits/Sasha-Levin/rtc-fix-overflow-and-incorrect-calculation-in-rtc_time64_to_tm/20151204-081508 base: https://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git rtc-next config: avr32-mimc200_defconfig (attached as .config) 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 # save the attached .config to linux build tree make.cross ARCH=avr32 All errors (new ones prefixed by >>): crypto/built-in.o: warning: input is not relaxable virt/built-in.o: warning: input is not relaxable drivers/built-in.o: In function `phy_device_create': >> (.text+0x3c70c): undefined reference to `__avr32_smod64' drivers/built-in.o: In function `phy_device_create': (.text+0x3c710): undefined reference to `__avr32_sdiv64' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
Re: [BUG] checkpatch: false positive for commits with quote characters
On Thu, Dec 03, 2015 at 04:36:28PM -0800, Joe Perches wrote:
> On Thu, 2015-12-03 at 16:29 -0800, Joe Perches wrote:
> > On Thu, 2015-12-03 at 16:13 -0800, Brian Norris wrote:
> > > Ping? I've hit some different false positives today on the same rule.
> > > I'll stop bothering to report them if no one cares.
> >
> > Perhaps this:
Aside from the non-breaking spaces your copy of Evolution inserted, it's
an improvement. (It doesn't give a false positive for the patch I
reported.) But it's still got some holes.
> (minus the debugging this time...)
> ---
> scripts/checkpatch.pl | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index d4960f7..b23dff8 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -2397,20 +2397,20 @@ sub process {
> $long = 1 if ($line =~ /\bcommit\s+[0-9a-f]{41,}/i);
> $space = 0 if ($line =~ /\bcommit [0-9a-f]/i);
> $case = 0 if ($line =~
> /\b[Cc]ommit\s+[0-9a-f]{5,40}[^A-F]/);
> - if ($line =~
> /\bcommit\s+[0-9a-f]{5,}\s+\("([^"]+)"\)/i) {
> + if ($line =~ /\bcommit\s+[0-9a-f]{5,}\s+\("(.*)"\)/i) {
You're got the reverse problem now. This will match too broadly. For
instance, if there is another instance of terminating quote +
parentheses on the same line, then we'll get a false postive. e.g., if I
wrote a patch that included something like this:
Commit 6dc0dcde406b ("parisc: Use
platform_device_register_simple("rtc-generic")") is cool (as in "cool")
Or even if it's wrapped like this:
Commit 6dc0dcde406b ("parisc: Use
platform_device_register_simple("rtc-generic")") is cool (as in "cool")
Then the regexes will think the description was:
parisc: Use platform_device_register_simple("rtc-generic")") is cool (as in
"cool
A hacky workaround for that one: only check for (loosely, not proper
regex syntax):
parsed_description =~ description . ")";
rather than:
description == parsed_description
Not sure how far you want to go on chasing false positives...
> $orig_desc = $1;
> $hasparens = 1;
> } elsif ($line =~ /\bcommit\s+[0-9a-f]{5,}\s*$/i &&
> defined $rawlines[$linenr] &&
> - $rawlines[$linenr] =~ /^\s*\("([^"]+)"\)/) {
> + $rawlines[$linenr] =~ /^\s*\("(.*)"\)/) {
> $orig_desc = $1;
> $hasparens = 1;
> } elsif ($line =~
> /\bcommit\s+[0-9a-f]{5,}\s+\("[^"]+$/i &&
> defined $rawlines[$linenr] &&
> - $rawlines[$linenr] =~ /^\s*[^"]+"\)/) {
> + $rawlines[$linenr] =~ /^\s*.*"\)/) {
> $line =~
> /\bcommit\s+[0-9a-f]{5,}\s+\("([^"]+)$/i;
> $orig_desc = $1;
> - $rawlines[$linenr] =~ /^\s*([^"]+)"\)/;
> + $rawlines[$linenr] =~ /^\s*(.*)"\)/;
> $orig_desc .= " " . $1;
> $hasparens = 1;
> }
BTW, another false positive: just including this text in a commit
triggers a different one:
http://lkml.kernel.org/g/20151113220039.ga74...@google.com
A simple hack (appended, in addition to yours) would be to assume that
when people are trying to include badly-formatted commit hashes, they
will be preceding them with whitespace, the beginning of a line, or
encapsulating punctuation. Or use a URL parser.
Brian
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index d2993f19df3f..e7110ba3242b 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2349,7 +2349,7 @@ sub process {
# Check for git id commit length and improperly formed commit descriptions
if ($in_commit_log && !$commit_log_possible_stack_dump &&
($line =~ /\bcommit\s+[0-9a-f]{5,}\b/i ||
-($line =~ /\b[0-9a-f]{12,40}\b/i &&
+($line =~ /\b[\s^\("][0-9a-f]{12,40}\b/i &&
$line !~ /[\<\[][0-9a-f]{12,40}[\>\]]/i &&
$line !~ /\bfixes:\s*[0-9a-f]{12,40}/i))) {
my $init_char = "c";
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/34] mm, gup: introduce concept of "foreign" get_user_pages()
From: Dave Hansen For protection keys, we need to understand whether protections should be enforced in software or not. In general, we enforce protections when working on our own task, but not when on others. We call these "current" and "foreign" operations. This introduces two new get_user_pages() variants: get_current_user_pages() get_foreign_user_pages() get_current_user_pages() is a drop-in replacement for when get_user_pages() was called with (current, current->mm, ...) as arguments. Using it makes a few of the call sites look a bit nicer. get_foreign_user_pages() is a replacement for when get_user_pages() is called on non-current tsk/mm. We leave a stub get_user_pages() around with a __deprecated warning. Signed-off-by: Dave Hansen Cc: Andrew Morton Cc: Kirill A. Shutemov Cc: Andrea Arcangeli Cc: Naoya Horiguchi --- b/arch/mips/mm/gup.c |3 - b/arch/s390/mm/gup.c |3 - b/arch/sh/mm/gup.c|2 - b/arch/sparc/mm/gup.c |2 - b/arch/x86/mm/gup.c |2 - b/arch/x86/mm/mpx.c |4 +- b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |4 +- b/drivers/gpu/drm/i915/i915_gem_userptr.c |2 - b/drivers/gpu/drm/radeon/radeon_ttm.c |4 +- b/drivers/gpu/drm/via/via_dmablit.c |3 - b/drivers/infiniband/core/umem.c |2 - b/drivers/infiniband/core/umem_odp.c |8 ++-- b/drivers/infiniband/hw/mthca/mthca_memfree.c |3 - b/drivers/infiniband/hw/qib/qib_user_pages.c |3 - b/drivers/infiniband/hw/usnic/usnic_uiom.c|2 - b/drivers/media/pci/ivtv/ivtv-udma.c |4 +- b/drivers/media/pci/ivtv/ivtv-yuv.c | 10 ++--- b/drivers/media/v4l2-core/videobuf-dma-sg.c |3 - b/drivers/misc/sgi-gru/grufault.c |3 - b/drivers/scsi/st.c |2 - b/drivers/video/fbdev/pvr2fb.c|4 +- b/drivers/virt/fsl_hypervisor.c |5 +- b/fs/exec.c |8 +++- b/include/linux/mm.h | 39 +-- b/kernel/events/uprobes.c |4 +- b/mm/frame_vector.c |2 - b/mm/gup.c| 51 -- b/mm/memory.c |2 - b/mm/mempolicy.c |6 +-- b/mm/nommu.c | 34 ++--- b/mm/process_vm_access.c |6 ++- b/mm/util.c |4 -- b/net/ceph/pagevec.c |2 - b/security/tomoyo/domain.c|9 b/virt/kvm/async_pf.c |2 - b/virt/kvm/kvm_main.c | 13 +++--- 36 files changed, 147 insertions(+), 113 deletions(-) diff -puN arch/mips/mm/gup.c~get_current_user_pages arch/mips/mm/gup.c --- a/arch/mips/mm/gup.c~get_current_user_pages 2015-12-03 16:21:17.700311841 -0800 +++ b/arch/mips/mm/gup.c2015-12-03 16:21:17.762314653 -0800 @@ -301,8 +301,7 @@ slow_irqon: start += nr << PAGE_SHIFT; pages += nr; - ret = get_user_pages_unlocked(current, mm, start, - (end - start) >> PAGE_SHIFT, + ret = get_user_pages_unlocked(start, (end - start) >> PAGE_SHIFT, write, 0, pages); /* Have to be a bit careful with return values */ diff -puN arch/s390/mm/gup.c~get_current_user_pages arch/s390/mm/gup.c --- a/arch/s390/mm/gup.c~get_current_user_pages 2015-12-03 16:21:17.701311886 -0800 +++ b/arch/s390/mm/gup.c2015-12-03 16:21:17.762314653 -0800 @@ -241,8 +241,7 @@ int get_user_pages_fast(unsigned long st /* Try to get the remaining pages with get_user_pages */ start += nr << PAGE_SHIFT; pages += nr; - ret = get_user_pages_unlocked(current, mm, start, -nr_pages - nr, write, 0, pages); + ret = get_user_pages_unlocked(start, nr_pages - nr, write, 0, pages); /* Have to be a bit careful with return values */ if (nr > 0) ret = (ret < 0) ? nr : ret + nr; diff -puN arch/sh/mm/gup.c~get_current_user_pages arch/sh/mm/gup.c --- a/arch/sh/mm/gup.c~get_current_user_pages 2015-12-03 16:21:17.703311977 -0800 +++ b/arch/sh/mm/gup.c 2015-12-03 16:21:17.762314653 -0800 @@ -257,7 +257,7 @@ slow_irqon: start += nr << PAGE_SHIFT; pages += nr; - ret = get_user_pages_unlocked(current, mm, start, + ret = get_user_pages_unlocked(start, (end - start) >> PAGE_SHIFT, write, 0, pages); /* Have to be a bit careful with return values */ diff -puN
