Re: [PATCH v4 1/4] mmc: dw_mmc: Don't try to enable the CD until we're sure we're not deferring
Hi, Doug.
This patch is not related with [patch 2/4~4/4].
"[PATCH v4 2/4] mmc: core: Add mmc_regulator_set_vqmmc()" is discussing..
So i think if you're ok, i will pick this one [PATCH v4 1/4]. how about?
Best Regards,
Jaehoon Chung
On 03/12/2015 07:15 AM, Doug Anderson wrote:
> If dw_mci_init_slot() returns that we got a probe deferral then it may
> leave slot->mmc as NULL. That will cause dw_mci_enable_cd() to crash
> when it calls mmc_gpio_get_cd().
>
> Fix this by moving the call of dw_mci_enable_cd() until we're sure
> that we're good. Note that if we have more than one slot and one
> defers (but the others don't) things won't work so well. ...but
> that's not a new thing and everyone has already agreed that multislot
> support ought to be removed from dw_mmc eventually anyway since it is
> unused, untested, and you can see several bugs like this by inspecting
> the code.
>
> Fixes: bcafaf5470f0 ("mmc: dw_mmc: Only enable CD after setup and only if
> needed")
> Signed-off-by: Doug Anderson
> ---
> Changes in v4:
> - Defer vs. card detect fix patch new for v4.
>
> Changes in v3: None
> Changes in v2: None
>
> drivers/mmc/host/dw_mmc.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 47dfd0e..e2811cf 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -2863,9 +2863,6 @@ int dw_mci_probe(struct dw_mci *host)
> init_slots++;
> }
>
> - /* Now that slots are all setup, we can enable card detect */
> - dw_mci_enable_cd(host);
> -
> if (init_slots) {
> dev_info(host->dev, "%d slots initialized\n", init_slots);
> } else {
> @@ -2874,6 +2871,9 @@ int dw_mci_probe(struct dw_mci *host)
> goto err_dmaunmap;
> }
>
> + /* Now that slots are all setup, we can enable card detect */
> + dw_mci_enable_cd(host);
> +
> if (host->quirks & DW_MCI_QUIRK_IDMAC_DTO)
> dev_info(host->dev, "Internal DMAC interrupt fix enabled.\n");
>
>
--
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 0/3] arm: msm: Use timer DT node for qcom watchdog config
On 02/20, Mathieu Olivari wrote: > This change is done as a follow-up to the following thread: > https://lkml.org/lkml/2014/10/1/436 > > qcom-wdt is currently assuming the presence of a dedicated node in DT > to gets its configuration. However, on msm architecture, the watchdog is > usually part of the timer block. So this patch-set is changing the driver > and slightly enhancing the timer DT bindings to provide the relevant clocks > and interrupts. > > Mathieu Olivari (3): > watchdog: qcom: use timer devicetree binding > ARM: qcom: add description of KPSS WDT for IPQ8064 > ARM: msm: add watchdog entries to DT timer binding doc > > Documentation/devicetree/bindings/arm/msm/timer.txt | 16 +--- > arch/arm/boot/dts/qcom-ipq8064.dtsi | 14 +- > drivers/watchdog/qcom-wdt.c | 21 > +++-- > 3 files changed, 41 insertions(+), 10 deletions(-) > Can this patchset be applied? Or should we resend with collected acks? -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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 00/11] an introduction of library operating system for Linux (LibOS)
Am 27.03.2015 um 04:49 schrieb Geert Uytterhoeven: > On Fri, Mar 27, 2015 at 4:31 AM, Rusty Russell wrote: >> Richard Weinberger writes: >>> This also infers that arch/lib will be broken most of the time as >>> every time the networking stack references a new symbol it >>> has to be duplicated into arch/lib. >>> >>> But this does not mean that your idea is bad, all I want to say that >>> I'm not sure whether arch/lib is the right approach. >>> Maybe Arnd has a better idea. >> >> Exactly why I look forward to getting this in-tree. Jeremy Kerr and I >> wrote nfsim back in 2005(!) which stubbed around the netfilter >> infrastructure; with failtest and valgrind it found some nasty bugs. It >> was too much hassle to maintain out-of-tree though :( >> >> I look forward to a flood of great bugfixes from this work :) > > IIRC, the ability to run UML under valgrind was also one of its key features? > And that's not limited to networking. Sadly this feature went never mainline. You needed a rather invading patch for both Linux and valgrind. But now with KASan we have a much more powerful feature to find issues. Thanks, //richard -- 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] clk: qcom: Fix ipq806x LCC frequency tables
On 03/02, Kenneth Westfield wrote: > On Thu, Feb 26, 2015 at 07:37:44PM -0800, Stephen Boyd wrote: > > These frequency tables list the wrong rates. Either they don't > > have the correct frequency at all, or they're specified in kHz > > instead of Hz. Fix it. > > > > Fixes: c99e515a92e9 "clk: qcom: Add IPQ806X LPASS clock controller (LCC) > > driver" > > Cc: Kenneth Westfield > > Signed-off-by: Stephen Boyd > > --- > > drivers/clk/qcom/lcc-ipq806x.c | 18 +- > > 1 file changed, 9 insertions(+), 9 deletions(-) > > Verified audio functionality on the Storm board (w/o SPDIF). > > Tested-by: Kenneth Westfield > Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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: s3c2410_udc: Remove static char buffer, use vsprintf extension %pV
Using unnecessary static char buffers isn't good.
Use the %pV extension instead.
Miscellanea:
o the dprintk return value is unused, make it void
o add __printf format and argument verification
Signed-off-by: Joe Perches
---
This doesn't matter much as it is pretty unusual to enable
printk support and CONFIG_USB_S3C2410_DEBUG for this board.
This is just for completeness.
Compiled with and without printk support, but otherwise untested.
drivers/usb/gadget/udc/s3c2410_udc.c | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/gadget/udc/s3c2410_udc.c
b/drivers/usb/gadget/udc/s3c2410_udc.c
index b808951..2979575 100644
--- a/drivers/usb/gadget/udc/s3c2410_udc.c
+++ b/drivers/usb/gadget/udc/s3c2410_udc.c
@@ -92,40 +92,38 @@ static struct s3c2410_udc_mach_info *udc_info;
static uint32_t s3c2410_ticks = 0;
-static int dprintk(int level, const char *fmt, ...)
+__printf(2, 3)
+static void dprintk(int level, const char *fmt, ...)
{
- static char printk_buf[1024];
static long prevticks;
static int invocation;
+ struct va_format vaf;
va_list args;
- int len;
if (level > USB_S3C2410_DEBUG_LEVEL)
- return 0;
+ return;
+
+ va_start(args, fmt);
+
+ vaf.fmt = fmt;
+ vaf.va =
if (s3c2410_ticks != prevticks) {
prevticks = s3c2410_ticks;
invocation = 0;
}
- len = scnprintf(printk_buf,
- sizeof(printk_buf), "%1lu.%02d USB: ",
- prevticks, invocation++);
+ pr_debug("%1lu.%02d USB: %pV", prevticks, invocation++, );
- va_start(args, fmt);
- len = vscnprintf(printk_buf+len,
- sizeof(printk_buf)-len, fmt, args);
va_end(args);
-
- pr_debug("%s", printk_buf);
- return len;
}
#else
-static int dprintk(int level, const char *fmt, ...)
+__printf(2, 3)
+static void dprintk(int level, const char *fmt, ...)
{
- return 0;
}
#endif
+
static int s3c2410_udc_debugfs_seq_show(struct seq_file *m, void *p)
{
u32 addr_reg, pwr_reg, ep_int_reg, usb_int_reg;
--
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] sched: Improve load balancing in the presence of idle CPUs
* Jason Low [2015-03-26 22:07:21]: > On Fri, 2015-03-27 at 10:12 +0800, Wanpeng Li wrote: > > Hi Preeti, > > On Thu, Mar 26, 2015 at 06:32:44PM +0530, Preeti U Murthy wrote: > > > > > >1. An ILB CPU was chosen from the first numa domain to trigger nohz idle > > >load balancing [Given the experiment, upto 6 CPUs per core could be > > >potentially idle in this domain.] > > > > > >2. However the ILB CPU would call load_balance() on itself before > > >initiating nohz idle load balancing. > > > > > >3. Given cores are SMT8, the ILB CPU had enough opportunities to pull > > >tasks from its sibling cores to even out load. > > > > > >4. Now that the ILB CPU was no longer idle, it would abort nohz idle > > >load balancing > > > > I don't see abort nohz idle load balancing when ILB CPU was no longer idle > > in nohz_idle_balance(), could you explain more in details? > > Hi Wanpeng, > > In nohz_idle_balance(), there is a check for need_resched() so if the > cpu has something to run, it should exit nohz_idle_balance(), which may > cause it to not do the idle balancing on the other CPUs. > Yes, the need_resched() in nohz_idle_balance() would exit the nohz_idle_balance if it has something to run. However I wonder if we should move the need_resched check out of the for loop. i.e the need_resched check should probably be there with the idle check. With the current code when the ilb cpus are not free: - We would be updating the nohz.next_balance even through we havent done any load balance. - We might iterate thro the nohz.idle_cpus_mask()s to find balance_cpus. -- Thanks and Regards Srikar Dronamraju -- 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] ring-buffer: More precise time stamps for nested writes
On 03/24/2015 06:19 PM, Steven Rostedt wrote: > On Tue, 24 Mar 2015 18:10:05 -0500 > .. .. > There is no architecture where disabling interrupts is cheap. Actually, > enabling them is the killer. Doing function tracing shows the impact of > this rather well, as it would disable and enable interrupts for every > function call, which can get rather expensive in the sum of things, and > it does skew the timings and can make it more difficult to debug > heissenbugs. > On PPC64, enabling and disabling soft IRQs is simply a matter of setting/clearing a per-CPU global variable (in the per-CPU PACA structure), so it shouldn't be expensive unless an interrupt is pending when we re-enable, which should be rare. I ran a series of tests on a Power8 box and even with a cold cache, both the local_irq_save and local_irq_restore routines only took a few nanoseconds, although the restore was a little more expensive than the save. (The restore took about 80-160 ns on a cold cache and 20-30 ns on a warm one.) > That said, I feel your pain. I've had some ideas about doing this > without disabling interrupts. That is excellent! > But for now, what can be done is to have > a flag that is set that will implement this or not. Using > static_branch() to implement it such that when its off it has no effect. > Are you recommending that for now I use a static_branch() instead of a CONFIG option to fix this? I could do that but the resulting code will either be messier to read (with several if condition checks) or will require some duplication of code. My assumption is that the new CONFIG option when disabled should have negligible impact since the compiler inlines the functions. -suresh > In the mean time, I can go and revisit trying to have better timings > with nested writes. > > -- 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/
[PATCH 3/4] [SMB3] Fix dereference before null check warning
null tcon is not likely in these paths in current
code, but obviously it does clarify the code to
check for null (if at all) before derefrencing
rather than after.
Reported by Coverity (CID 1042666)
Signed-off-by: Steve French
---
fs/cifs/smb2pdu.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
index 1b906de..78b329f 100644
--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -1218,7 +1218,7 @@ SMB2_ioctl(const unsigned int xid, struct cifs_tcon
*tcon, u64 persistent_fid,
struct smb2_ioctl_req *req;
struct smb2_ioctl_rsp *rsp;
struct TCP_Server_Info *server;
- struct cifs_ses *ses = tcon->ses;
+ struct cifs_ses *ses;
struct kvec iov[2];
int resp_buftype;
int num_iovecs;
@@ -1233,6 +1233,11 @@ SMB2_ioctl(const unsigned int xid, struct cifs_tcon
*tcon, u64 persistent_fid,
if (plen)
*plen = 0;
+ if (tcon)
+ ses = tcon->ses;
+ else
+ return -EIO;
+
if (ses && (ses->server))
server = ses->server;
else
@@ -1296,14 +1301,12 @@ SMB2_ioctl(const unsigned int xid, struct cifs_tcon
*tcon, u64 persistent_fid,
rsp = (struct smb2_ioctl_rsp *)iov[0].iov_base;
if ((rc != 0) && (rc != -EINVAL)) {
- if (tcon)
- cifs_stats_fail_inc(tcon, SMB2_IOCTL_HE);
+ cifs_stats_fail_inc(tcon, SMB2_IOCTL_HE);
goto ioctl_exit;
} else if (rc == -EINVAL) {
if ((opcode != FSCTL_SRV_COPYCHUNK_WRITE) &&
(opcode != FSCTL_SRV_COPYCHUNK)) {
- if (tcon)
- cifs_stats_fail_inc(tcon, SMB2_IOCTL_HE);
+ cifs_stats_fail_inc(tcon, SMB2_IOCTL_HE);
goto ioctl_exit;
}
}
--
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 4/4] [SMB3] Fix coverity warning
Coverity reports a warning for referencing the beginning of the SMB2/SMB3 frame using the ProtocolId field as an array. Although it works the same either way, this patch should quiet the warning and might be a little clearer. Reported by Coverity (CID 741269) Signed-off-by: Steve French --- fs/cifs/smb2misc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/cifs/smb2misc.c b/fs/cifs/smb2misc.c index 689f035..22dfdf1 100644 --- a/fs/cifs/smb2misc.c +++ b/fs/cifs/smb2misc.c @@ -322,7 +322,7 @@ smb2_get_data_area_len(int *off, int *len, struct smb2_hdr *hdr) /* return pointer to beginning of data area, ie offset from SMB start */ if ((*off != 0) && (*len != 0)) - return hdr->ProtocolId + *off; + return (char *)(>ProtocolId[0]) + *off; else return NULL; } -- 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] [CIFS] Don't ignore errors on encrypting password in SMBTcon
Although unlikely to fail (and tree connect does not commonly send
a password since SECMODE_USER is the default for most servers)
do not ignore errors on SMBNTEncrypt in SMB Tree Connect.
Reported by Coverity (CID 1226853)
Signed-off-by: Steve French
---
fs/cifs/connect.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index 4cb8450..cdb1aaf 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -3696,6 +3696,12 @@ CIFSTCon(const unsigned int xid, struct cifs_ses *ses,
#endif /* CIFS_WEAK_PW_HASH */
rc = SMBNTencrypt(tcon->password, ses->server->cryptkey,
bcc_ptr, nls_codepage);
+ if (rc) {
+ cifs_dbg(FYI, "%s Can't generate NTLM rsp. Error: %d\n",
+__func__, rc);
+ cifs_buf_release(smb_buffer);
+ return rc;
+ }
bcc_ptr += CIFS_AUTH_RESP_SIZE;
if (ses->capabilities & CAP_UNICODE) {
--
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/4] [SMB3] Fix warning on uninitialized buftype
Pointed out by coverity analyzer. resp_buftype is not initialized in one path which can rarely log a spurious warning (buf is null so there will not be a problem with freeing data, but if buf_type were randomly set to wrong value could log a warning) Reported by Coverity (CID 1269144) Signed-off-by: Steve French --- fs/cifs/smb2pdu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c index 3417340..1b906de 100644 --- a/fs/cifs/smb2pdu.c +++ b/fs/cifs/smb2pdu.c @@ -2114,7 +2114,7 @@ SMB2_query_directory(const unsigned int xid, struct cifs_tcon *tcon, struct kvec iov[2]; int rc = 0; int len; - int resp_buftype; + int resp_buftype = CIFS_NO_BUFFER; unsigned char *bufptr; struct TCP_Server_Info *server; struct cifs_ses *ses = tcon->ses; -- 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] Fix various coverity warnings in fs/cifs
Four small fixes to address warnings coverity analyzer displays for fs/cifs. Steve French (4): [SMB3] Fix warning on uninitialized buftype [CIFS] Don't ignore errors on encrypting password in SMBTcon [SMB3] Fix dereference before null check warning [SMB3] Fix coverity warning fs/cifs/connect.c | 6 ++ fs/cifs/smb2misc.c | 2 +- fs/cifs/smb2pdu.c | 15 +-- 3 files changed, 16 insertions(+), 7 deletions(-) -- 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 04/13] thermal: Fix not emulating critical temperatures
Hi Amit,
On Fri, Mar 27, 2015 at 08:35:50AM +0530, amit daniel kachhap wrote:
> Hi Sascha,
>
> > -#ifdef CONFIG_THERMAL_EMULATION
> > - if (!tz->emul_temperature)
> > - goto skip_emul;
> > -
> > - for (count = 0; count < tz->trips; count++) {
> > - ret = tz->ops->get_trip_type(tz, count, );
> > - if (!ret && type == THERMAL_TRIP_CRITICAL) {
> > - ret = tz->ops->get_trip_temp(tz, count, _temp);
> > - break;
> > - }
> > - }
> > -
> > - if (ret)
> > - goto skip_emul;
> >
> > - if (*temp < crit_temp)
> I guess this check is confusing. Actually instead of returning
> emulating temperature it is returning actual temperature. But the
> important thing to look here is that actual temperature is higher than
> critical temperature. So this check prevents the user from suppressing
> the critical temperature and hence prevents from burning up the chip.
Indeed the check is confusing, but now it makes perfectly sense. I'll
look at the patch again and maybe turn into a patch just adding a
comment to clarify this.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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] xen-blkback: enlarge the array size of blkback name
The blkback name is like blkback.domid.xvd[a-z], if domid has four digits
(means larger than 1000), then the backmost xvd wouldn't be fully shown.
Define a BLKBACK_NAME_LEN macro to be 20, enlarge the array size of
blkback name, so it will be fully shown in any case.
Signed-off-by: Tao Chen
---
v2:
- Change the value of BLKBACK_NAME_LEN macro from (TASK_COMM_LEN * 2)
to 20. Because 20 is already safe for the length of blkback name.
---
drivers/block/xen-blkback/xenbus.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/block/xen-blkback/xenbus.c
b/drivers/block/xen-blkback/xenbus.c
index e3afe97..b33083e 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -21,6 +21,9 @@
#include
#include "common.h"
+/* Enlarge the array size in order to fully show blkback name. */
+#define BLKBACK_NAME_LEN (20)
+
struct backend_info {
struct xenbus_device*dev;
struct xen_blkif*blkif;
@@ -70,7 +73,7 @@ static int blkback_name(struct xen_blkif *blkif, char *buf)
else
devname = devpath;
- snprintf(buf, TASK_COMM_LEN, "blkback.%d.%s", blkif->domid, devname);
+ snprintf(buf, BLKBACK_NAME_LEN, "blkback.%d.%s", blkif->domid, devname);
kfree(devpath);
return 0;
@@ -79,7 +82,7 @@ static int blkback_name(struct xen_blkif *blkif, char *buf)
static void xen_update_blkif_status(struct xen_blkif *blkif)
{
int err;
- char name[TASK_COMM_LEN];
+ char name[BLKBACK_NAME_LEN];
/* Not ready to connect? */
if (!blkif->irq || !blkif->vbd.bdev)
--
1.8.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/
[PATCH] perf: .gitignore: ignore .config-detected.
Commit fcfd6611fbccdbf2593bd949097a5c0e45cd96da ("tools build: Add
detected config support") dynamically creates .config-detected. Add it
to .gitignore.
Signed-off-by: Wang Nan
---
tools/perf/.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/perf/.gitignore b/tools/perf/.gitignore
index 812f904..09db62b 100644
--- a/tools/perf/.gitignore
+++ b/tools/perf/.gitignore
@@ -28,3 +28,4 @@ config.mak.autogen
*-flex.*
*.pyc
*.pyo
+.config-detected
--
1.8.3.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/
Re: [PATCH v1] arm64:mm: enable the kernel execute attribute for HEAD_TEXT segment
Hi, Mark
On 2015/3/27 6:10, Mark Rutland wrote:
On Thu, Mar 26, 2015 at 01:53:48PM +, Zhichang Yuan wrote:
From: yuanzhichang
In the patch whose title is "add better page protections to arm64"
(commit da141706aea52c1a9fbd28cb8d289b78819f5436), The direct mapping
page table entries for HEAD_TEXT segment were configured as PAGE_KERNEL,
without the executable attribute. But when the secondary CPUs are booting
based on spin-table mechanism, some functions in head.S are needed to run.
In mainline today, the only functions I see in head.S before the .section
change (and hence are not executable) are:
* stext
* __vet_fdt
* __create_page_tables
* __mmap_switched
These are never executed by secondary CPUs. So your problem does not seem to be
related to functions falling withing HEAD_TEXT -- all other functions in head.S
are placed in .text, and thus will be executable regardless.
Yes. It is my fault. We had not used the new kernel version to do the
test. The functions needed for secondary CPUs and CPU restarting are not
put into the text section. I checked the head.S in the source tree for
our board, there is no this instruction in head.S:
.section ".text","ax"
Thank you very much!
Sorry for the disturbance caused by this patch:(
-Zhichang
-
If you had a problem with spin-table, then I don't see why it wouldn't also
apply to PSCI -- in both cases we go via secondary_startup before we enable the
MMU.
So I suspect that you have another bug, and some layout change (or difference
in maintenance) is masking that when the better protections are enabled. It's
also possible that we have a bug in the logic updating the page tables.
Have you actually seen an issue, or was this theoretical?
What exactly do you see happen when booting secondary CPUs?
Do you see the issue in mainline?
Only PAGE_KERNEL dosen't work for this case.
This patch will configure the page attributes as PAGE_KERNEL_EXEC for
HEAD_TEXT segment.
I don't see how this should be necessary. All the text in that section should
only be executed on the first CPU, prior to permissions being applied, and
prior to the MMU being enabled.
Signed-off-by: Zhichang Yuan
---
arch/arm64/mm/mmu.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index c6daaf6..ad08dfd 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -305,8 +305,8 @@ static void __init __map_memblock(phys_addr_t start,
phys_addr_t end)
* for now. This will get more fine grained later once all memory
* is mapped
*/
- unsigned long kernel_x_start = round_down(__pa(_stext), SECTION_SIZE);
- unsigned long kernel_x_end = round_up(__pa(__init_end), SECTION_SIZE);
+ phys_addr_t kernel_x_start = round_down(__pa(_text), SECTION_SIZE);
+ phys_addr_t kernel_x_end = round_up(__pa(__init_end), SECTION_SIZE);
As mentioned above, none of the text in this section needs to be run with the
MMU on. So I don't think this is necessary.
if (end < kernel_x_start) {
create_mapping(start, __phys_to_virt(start),
@@ -315,6 +315,18 @@ static void __init __map_memblock(phys_addr_t start,
phys_addr_t end)
create_mapping(start, __phys_to_virt(start),
end - start, PAGE_KERNEL);
} else {
+ /*
+* At this moment, the text segment must reside in valid physical
+* memory section range to make sure the text are totally mapped.
+* If mapping from non-section aligned address is support, then
+* _text can be used here directly in replace to kernel_x_start.
+*/
+ phys_addr_t max_left, min_right;
+
+ max_left = max(kernel_x_start, start);
+ min_right = min(kernel_x_end, end);
+ BUG_ON(max_left != kernel_x_start || min_right != kernel_x_end);
Huh?
Mark.
.
--
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] sched: Improve load balancing in the presence of idle CPUs
On Fri, 2015-03-27 at 10:12 +0800, Wanpeng Li wrote: > Hi Preeti, > On Thu, Mar 26, 2015 at 06:32:44PM +0530, Preeti U Murthy wrote: > > > >1. An ILB CPU was chosen from the first numa domain to trigger nohz idle > >load balancing [Given the experiment, upto 6 CPUs per core could be > >potentially idle in this domain.] > > > >2. However the ILB CPU would call load_balance() on itself before > >initiating nohz idle load balancing. > > > >3. Given cores are SMT8, the ILB CPU had enough opportunities to pull > >tasks from its sibling cores to even out load. > > > >4. Now that the ILB CPU was no longer idle, it would abort nohz idle > >load balancing > > I don't see abort nohz idle load balancing when ILB CPU was no longer idle > in nohz_idle_balance(), could you explain more in details? Hi Wanpeng, In nohz_idle_balance(), there is a check for need_resched() so if the cpu has something to run, it should exit nohz_idle_balance(), which may cause it to not do the idle balancing on the other CPUs. -- 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] sched: Improve load balancing in the presence of idle CPUs
On Fri, 2015-03-27 at 10:03 +0530, Preeti U Murthy wrote: > Hi Wanpeng > > On 03/27/2015 07:42 AM, Wanpeng Li wrote: > > Hi Preeti, > > On Thu, Mar 26, 2015 at 06:32:44PM +0530, Preeti U Murthy wrote: > >> > >> 1. An ILB CPU was chosen from the first numa domain to trigger nohz idle > >> load balancing [Given the experiment, upto 6 CPUs per core could be > >> potentially idle in this domain.] > >> > >> 2. However the ILB CPU would call load_balance() on itself before > >> initiating nohz idle load balancing. > >> > >> 3. Given cores are SMT8, the ILB CPU had enough opportunities to pull > >> tasks from its sibling cores to even out load. > >> > >> 4. Now that the ILB CPU was no longer idle, it would abort nohz idle > >> load balancing > > > > I don't see abort nohz idle load balancing when ILB CPU was no longer idle > > in nohz_idle_balance(), could you explain more in details? > > When the ILB CPU pulls load in rebalance_domains(), its idle state > is set to CPU_NOT_IDLE. > > "" > idle = idle_cpu(cpu) ? CPU_IDLE : CPU_NOT_IDLE; Hi Preeti, The "idle" variable is a local variable to the rebalance_domains() function. In that case, that shouldn't have an affect on the idle value that gets passed to nohz_idle_balance(). -- 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: linux-next: manual merge of the dt-rh tree with the mips tree
On Thu, Mar 26, 2015 at 11:56 PM, Scott Branden wrote: > Rob, > > Apologies that the mips tree is deleting files that I was synchronizing names > on. Would you like me to provide new patch that doesn't touch files that > mips tree is now deleting? No, it is fine. I'd rather not rebase my tree. Rob -- 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: linux-next: manual merge of the dt-rh tree with the mips tree
Rob, Apologies that the mips tree is deleting files that I was synchronizing names on. Would you like me to provide new patch that doesn't touch files that mips tree is now deleting? Scott > On Mar 26, 2015, at 9:26 PM, Stephen Rothwell wrote: > > -- 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] vmstat: Avoid waking up idle-cpu to service shepherd work
On 27 March 2015 at 01:48, Andrew Morton wrote: > Shouldn't this be viewed as a shortcoming of the core timer code? Yeah, it is. Some (not so pretty) solutions were tried earlier to fix that, but they are rejected for obviously reasons [1]. > vmstat_shepherd() is merely rescheduling itself with > schedule_delayed_work(). That's a dead bog simple operation and if > it's producing suboptimal behaviour then we shouldn't be fixing it with > elaborate workarounds in the caller? I understand that, and that's why I sent it as an RFC to get the discussion started. Does anyone else have got another (acceptable) idea to get this resolved ? -- viresh [1] http://lists.linaro.org/pipermail/linaro-kernel/2013-November/008866.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/
Re: [PATCH 3/5] arm64: kdump: do not go into EL2 before starting a crash dump kernel
On Thu, 2015-03-26 at 17:28 +0900, AKASHI Takahiro wrote: > @@ -64,7 +65,11 @@ void soft_restart(unsigned long addr) > setup_mm_for_reboot(); > > cpu_soft_restart(virt_to_phys(cpu_reset), > - is_hyp_mode_available(), addr); > +#ifdef CONFIG_KEXEC > + !in_crash_kexec && > +#endif Why not define in_crash_kexec without condition on CONFIG_KEXEC, say here in process.c and then avoid these preprocessor conditionals. > + is_hyp_mode_available(), > + addr); > > /* Should never get here */ > BUG(); -- 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 1/5] arm64: kdump: reserve memory for crash dump kernel
Hi Takahiro,
On Thu, 2015-03-26 at 17:28 +0900, AKASHI Takahiro wrote:
> On system kernel, the memory region used by crash dump kernel must be
> specified by "crashkernel=X@Y" boot parameter. reserve_crashkernel()
> will allocate the region in "System RAM" and reserve it for later use.
>
> On crash dump kernel, memory region information in system kernel is
> described in a specific region specified by "elfcorehdr=X@Y" boot parameter.
> reserve_elfcorehdr() will set aside the region to avoid data destruction
> by the kernel.
>
> Crash dump kernel will access memory regions in system kernel via
> copy_oldmem_page(), which reads a page with ioremap'ing it assuming that
s/page with/page by/
> such pages are not part of main memory of crash dump kernel.
> This is true under non-UEFI environment because kexec-tools modifies
> a device tree adding "usablemem" attributes to memory sections.
> Under UEFI, however, this is not true because UEFI remove memory sections
> in a device tree and export all the memory regions, even though they belong
> to system kernel.
>
> So we should add "mem=X[MG]" boot parameter to limit the meory size and
s/meory/memory/
> avoid hitting the following assertion in ioremap():
> if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr
> return NULL;
>
> Signed-off-by: AKASHI Takahiro
> ---
> arch/arm64/kernel/Makefile |1 +
> arch/arm64/kernel/crash_dump.c | 71
> arch/arm64/kernel/setup.c | 78
>
> 3 files changed, 150 insertions(+)
> create mode 100644 arch/arm64/kernel/crash_dump.c
>
> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> index da9a7ee..3c24d4e 100644
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -36,6 +36,7 @@ arm64-obj-$(CONFIG_EFI) += efi.o
> efi-stub.o efi-entry.o
> arm64-obj-$(CONFIG_PCI) += pci.o
> arm64-obj-$(CONFIG_ARMV8_DEPRECATED) += armv8_deprecated.o
> arm64-obj-$(CONFIG_KEXEC)+= machine_kexec.o relocate_kernel.o
> +arm64-obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
>
> obj-y+= $(arm64-obj-y) vdso/
> obj-m+= $(arm64-obj-m)
> diff --git a/arch/arm64/kernel/crash_dump.c b/arch/arm64/kernel/crash_dump.c
> new file mode 100644
> index 000..dd31b2e
> --- /dev/null
> +++ b/arch/arm64/kernel/crash_dump.c
> @@ -0,0 +1,71 @@
> +/*
> + * arch/arm64/kernel/crash_dump.c
I would recommend against adding paths in source files. It often
happens that files with paths are moved, but the file comments are not
updated.
> + *
> + * Copyright (C) 2014 Linaro Limited
> + * Author: AKASHI Takahiro
> + *
> + * 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
> +
> +/**
> + * copy_oldmem_page() - copy one page from old kernel memory
> + * @pfn: page frame number to be copied
> + * @buf: buffer where the copied page is placed
> + * @csize: number of bytes to copy
> + * @offset: offset in bytes into the page
> + * @userbuf: if set, @buf is int he user address space
s/is int he user/is a user/
> + *
> + * This function copies one page from old kernel memory into buffer pointed
> by
> + * @buf. If @buf is in userspace, set @userbuf to %1. Returns number of bytes
> + * copied or negative error in case of failure.
> + */
> +ssize_t copy_oldmem_page(unsigned long pfn, char *buf,
> + size_t csize, unsigned long offset,
> + int userbuf)
Since userbuf is a binary flag, I think type bool would be better.
Change the comments from 'set' and '1' to 'true'.
Should offset be type size_t?
> +{
> + void *vaddr;
> +
> + if (!csize)
> + return 0;
> +
> + vaddr = ioremap(pfn << PAGE_SHIFT, PAGE_SIZE);
> + if (!vaddr)
> + return -ENOMEM;
> +
> + if (userbuf) {
> + if (copy_to_user(buf, vaddr + offset, csize)) {
> + iounmap(vaddr);
> + return -EFAULT;
> + }
> + } else {
> + memcpy(buf, vaddr + offset, csize);
> + }
> +
> + iounmap(vaddr);
> +
> + return csize;
> +}
> +
> +/**
> + * elfcorehdr_read - read from ELF core header
> + * @buf: buffer where the data is placed
> + * @csize: number of bytes to read
> + * @ppos: address in the memory
> + *
> + * This function reads @count bytes from elf core header which exists
> + * on crash dump kernel's memory.
> + */
> +ssize_t elfcorehdr_read(char *buf, size_t count, u64 *ppos)
Should ppos be type phys_addr_t *?
> +{
> + memcpy(buf, phys_to_virt((phys_addr_t)*ppos), count);
> + return count;
> +}
> diff --git
Re: [PATCH V2] sched: Improve load balancing in the presence of idle CPUs
Hi Preeti, On Fri, Mar 27, 2015 at 10:03:21AM +0530, Preeti U Murthy wrote: >is set to CPU_NOT_IDLE. > >"" >idle = idle_cpu(cpu) ? CPU_IDLE : CPU_NOT_IDLE; > >And, > >When nohz_idle_balance() is called, the state of idle of ILB CPU is >checked before proceeding with load balancing on idle CPUs. > >"" > >if (idle != CPU_IDLE || > !test_bit(NOHZ_BALANCE_KICK, nohz_flags(this_cpu))) > goto end; > This idle is the one caculated in run_rebalance_domains() before invoke rebalance_domains(), rebalance_domains() cannot modify this local variable. Regards, Wanpeng Li >You see that nohz idle balancing gets aborted. > >Regards >Preeti U Murthy > > > >> >> Regards, >> Wanpeng Li >> -- 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 1/5] arm64: kdump: reserve memory for crash dump kernel
Hi Takahiro,
On Thu, 2015-03-26 at 17:28 +0900, AKASHI Takahiro wrote:
> On system kernel, the memory region used by crash dump kernel must be
> specified by "crashkernel=X@Y" boot parameter. reserve_crashkernel()
> will allocate the region in "System RAM" and reserve it for later use.
>
> On crash dump kernel, memory region information in system kernel is
> described in a specific region specified by "elfcorehdr=X@Y" boot parameter.
> reserve_elfcorehdr() will set aside the region to avoid data destruction
> by the kernel.
>
> Crash dump kernel will access memory regions in system kernel via
> copy_oldmem_page(), which reads a page with ioremap'ing it assuming that
s/page with/page by/
> such pages are not part of main memory of crash dump kernel.
> This is true under non-UEFI environment because kexec-tools modifies
> a device tree adding "usablemem" attributes to memory sections.
> Under UEFI, however, this is not true because UEFI remove memory sections
> in a device tree and export all the memory regions, even though they belong
> to system kernel.
>
> So we should add "mem=X[MG]" boot parameter to limit the meory size and
s/meory/memory/
> avoid hitting the following assertion in ioremap():
> if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr
> return NULL;
>
> Signed-off-by: AKASHI Takahiro
> ---
> arch/arm64/kernel/Makefile |1 +
> arch/arm64/kernel/crash_dump.c | 71
> arch/arm64/kernel/setup.c | 78
>
> 3 files changed, 150 insertions(+)
> create mode 100644 arch/arm64/kernel/crash_dump.c
>
> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> index da9a7ee..3c24d4e 100644
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -36,6 +36,7 @@ arm64-obj-$(CONFIG_EFI) += efi.o
> efi-stub.o efi-entry.o
> arm64-obj-$(CONFIG_PCI) += pci.o
> arm64-obj-$(CONFIG_ARMV8_DEPRECATED) += armv8_deprecated.o
> arm64-obj-$(CONFIG_KEXEC)+= machine_kexec.o relocate_kernel.o
> +arm64-obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
>
> obj-y+= $(arm64-obj-y) vdso/
> obj-m+= $(arm64-obj-m)
> diff --git a/arch/arm64/kernel/crash_dump.c b/arch/arm64/kernel/crash_dump.c
> new file mode 100644
> index 000..dd31b2e
> --- /dev/null
> +++ b/arch/arm64/kernel/crash_dump.c
> @@ -0,0 +1,71 @@
> +/*
> + * arch/arm64/kernel/crash_dump.c
I would recommend against adding paths in source files. It often
happens that files with paths are moved, but the file comments are not
updated.
> + *
> + * Copyright (C) 2014 Linaro Limited
> + * Author: AKASHI Takahiro
> + *
> + * 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
> +
> +/**
> + * copy_oldmem_page() - copy one page from old kernel memory
> + * @pfn: page frame number to be copied
> + * @buf: buffer where the copied page is placed
> + * @csize: number of bytes to copy
> + * @offset: offset in bytes into the page
> + * @userbuf: if set, @buf is int he user address space
s/is int he user/is a user/
> + *
> + * This function copies one page from old kernel memory into buffer pointed
> by
> + * @buf. If @buf is in userspace, set @userbuf to %1. Returns number of bytes
> + * copied or negative error in case of failure.
> + */
> +ssize_t copy_oldmem_page(unsigned long pfn, char *buf,
> + size_t csize, unsigned long offset,
> + int userbuf)
Since userbuf is a binary flag, I think type bool would be better.
Change the comments from 'set' and '1' to 'true'.
Should offset be type size_t?
> +{
> + void *vaddr;
> +
> + if (!csize)
> + return 0;
> +
> + vaddr = ioremap(pfn << PAGE_SHIFT, PAGE_SIZE);
> + if (!vaddr)
> + return -ENOMEM;
> +
> + if (userbuf) {
> + if (copy_to_user(buf, vaddr + offset, csize)) {
> + iounmap(vaddr);
> + return -EFAULT;
> + }
> + } else {
> + memcpy(buf, vaddr + offset, csize);
> + }
> +
> + iounmap(vaddr);
> +
> + return csize;
> +}
> +
> +/**
> + * elfcorehdr_read - read from ELF core header
> + * @buf: buffer where the data is placed
> + * @csize: number of bytes to read
> + * @ppos: address in the memory
> + *
> + * This function reads @count bytes from elf core header which exists
> + * on crash dump kernel's memory.
> + */
> +ssize_t elfcorehdr_read(char *buf, size_t count, u64 *ppos)
Should ppos be type phys_addr_t *?
> +{
> + memcpy(buf, phys_to_virt((phys_addr_t)*ppos), count);
> + return count;
> +}
> diff --git
[PATCH 1/2] phy: dt-binding: document Conexant Digicolor USB PHY
Add a device tree binding documentation to the USB PHY hardware block on the
Conexant CX92755 SoC. The CX92755 is one of the Digicolor SoCs series. Other
SoCs in that series may share the same hardware block.
Signed-off-by: Baruch Siach
---
.../devicetree/bindings/phy/digicolor-usb-phy.txt | 15 +++
1 file changed, 15 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/digicolor-usb-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/digicolor-usb-phy.txt
b/Documentation/devicetree/bindings/phy/digicolor-usb-phy.txt
new file mode 100644
index ..089f218c59c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/digicolor-usb-phy.txt
@@ -0,0 +1,15 @@
+Conexant Digicolor USB2 PHY
+
+Required properties:
+ - compatible: cnxt,cx92755-usbphy
+ - reg: offset and length of the PHY registers
+ - #phy-cells: must be 0
+Refer to phy-bindings.txt for the generic PHY binding properties
+
+Example:
+
+ usb_phy0: usb-phy@f0084000 {
+ compatible = "cnxt,cx92755-usbphy";
+ reg = <0xf0084000 0x100>;
+ #phy-cells = <0>;
+ };
--
2.1.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/2] phy: driver for Conexant Digicolor internal USB PHY
Add a driver for the USB PHY on the Conexant CX92755 SoC, from the Digicolor
series of SoCs. The PHY is connected to the on-chip chipidea usb2 host.
The hardware is somewhat similar to the phy-mxs-usb.c usb_phy, but it is
different enough to merit its own driver. Also, this driver uses the generic
phy infrastructure.
Cc: Marek Vasut
Cc: Richard Zhao
Signed-off-by: Baruch Siach
---
drivers/phy/Kconfig | 9 ++
drivers/phy/Makefile| 1 +
drivers/phy/phy-digicolor-usb.c | 209
3 files changed, 219 insertions(+)
create mode 100644 drivers/phy/phy-digicolor-usb.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 2962de205ba7..9589056ef5c7 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -291,4 +291,13 @@ config PHY_QCOM_UFS
help
Support for UFS PHY on QCOM chipsets.
+config PHY_DIGICOLOR_USB
+ tristate "Conexant Digicolor USB2 PHY Driver"
+ depends on ARCH_DIGICOLOR
+ select GENERIC_PHY
+ select USB_PHY
+ help
+ Enable this to support the USB 2.0 PHY that is part of Conexant
+ Digicolor SoC series.
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index f080e1bb2a74..392cb60d0240 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -38,3 +38,4 @@ obj-$(CONFIG_PHY_STIH41X_USB) += phy-stih41x-usb.o
obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o
obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-20nm.o
obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-14nm.o
+obj-$(CONFIG_PHY_DIGICOLOR_USB)+= phy-digicolor-usb.o
diff --git a/drivers/phy/phy-digicolor-usb.c b/drivers/phy/phy-digicolor-usb.c
new file mode 100644
index ..a1d7503530a0
--- /dev/null
+++ b/drivers/phy/phy-digicolor-usb.c
@@ -0,0 +1,209 @@
+/*
+ * Conexant Digicolor Integrated USB PHY driver
+ *
+ * Copyright (C) 2014, 2015 Paradox Innovation Ltd.
+ *
+ * Author: Baruch Siach
+ *
+ * Based on phy-mxs-usb.c.
+ *
+ * Copyright 2012-2014 Freescale Semiconductor, Inc.
+ * Copyright (C) 2012 Marek Vasut
+ * on behalf of DENX Software Engineering GmbH
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_NAME "digicolor_usb_phy"
+
+#define HW_USBPHY_PWD 0x00
+#define HW_USBPHY_TX 0x10
+#define HW_USBPHY_CTRL 0x30
+#define HW_USBPHY_CTRL_SET 0x34
+#define HW_USBPHY_CTRL_CLR 0x38
+
+#define HW_USBPHY_DEBUG0x50
+
+#define HW_USBPHY_IP 0x90
+#define HW_USBPHY_IP_SET 0x94
+#define HW_USBPHY_IP_CLR 0x98
+
+#define BM_USBPHY_CTRL_SFTRST BIT(31)
+#define BM_USBPHY_CTRL_CLKGATE BIT(30)
+#define BM_USBPHY_CTRL_ENHOSTDISCONDETECT BIT(1)
+
+#define BM_USBPHY_IP_EN_USB_CLKS BIT(2)
+#define BM_USBPHY_IP_PLL_LOCKEDBIT(1)
+#define BM_USBPHY_IP_PLL_POWER BIT(0)
+
+struct dc_usb_phy {
+ struct usb_phy phy;
+ struct device *dev;
+ void __iomem*regs;
+};
+
+static int digicolor_phy_init(struct phy *gphy)
+{
+ struct dc_usb_phy *phy = phy_get_drvdata(gphy);
+
+ /* Disable PLL */
+ writel(BM_USBPHY_IP_EN_USB_CLKS, phy->regs + HW_USBPHY_IP_CLR);
+ udelay(250);
+ writel(BM_USBPHY_IP_PLL_LOCKED, phy->regs + HW_USBPHY_IP_CLR);
+ udelay(250);
+ writel(BM_USBPHY_IP_PLL_POWER, phy->regs + HW_USBPHY_IP_CLR);
+ udelay(250);
+
+ /* Reset PHY */
+ writel(BM_USBPHY_CTRL_SFTRST, phy->regs + HW_USBPHY_CTRL_SET);
+ udelay(1000);
+ writel(BM_USBPHY_CTRL_SFTRST, phy->regs + HW_USBPHY_CTRL_CLR);
+ udelay(1000);
+
+ /* Enable PHY clock */
+ writel(BM_USBPHY_CTRL_CLKGATE, phy->regs + HW_USBPHY_CTRL_CLR);
+ udelay(250);
+
+ /* Enable PLL */
+ writel(BM_USBPHY_IP_PLL_POWER, phy->regs + HW_USBPHY_IP_SET);
+ udelay(250);
+ writel(BM_USBPHY_IP_PLL_LOCKED, phy->regs + HW_USBPHY_IP_SET);
+ udelay(250);
+ writel(BM_USBPHY_IP_EN_USB_CLKS, phy->regs + HW_USBPHY_IP_SET);
+ udelay(250);
+
+ /* Power PHY up */
+ writel(0, phy->regs + HW_USBPHY_PWD);
+ udelay(250);
+
+ /* Set resistors parameters (power up default values) */
+ writel(0x10060607, phy->regs + HW_USBPHY_TX);
+ writel(0x7f18, phy->regs + HW_USBPHY_DEBUG);
+
+ return 0;
+}
+
+static int digicolor_phy_shutdown(struct phy *gphy)
+{
+ struct dc_usb_phy
Re: [PATCH v2] cpufreq: powernv: Add checks to report cpu frequency throttling conditions
Hi Shilpa,
On 27 March 2015 at 00:11, Shilpasri G Bhat
wrote:
> Cpu frequency can be throttled due to failures of components like OCC,
> power supply and fan. It can also be throttled due to temperature and
> power limit. We can detect the throttling by checking 1)if max frequency
Add these points in separate lines please, with a space after ). Its not
readable this way..
> is reduced, 2)if the core is put to safe frequency 3)if the SPR based
> frequency management is disabled.
All these three points refer to the state CPU has shifted to ? Sorry it wasn't
clear to the outsiders :), perhaps some more detail on why CPU would have
done that.
> The current status of the core is read from Power Management Status
> Register(PMSR) to check if any of the throttling condition is
> occurred and the appropriate throttling message is reported.
So, what do we want to do on throttling? Just print a warning? Is that
enough? What if CPU gets heated up to a point that it burns up ?
> Signed-off-by: Shilpasri G Bhat
> ---
> Changes from V1: Removed unused value of PMCR register
>
> drivers/cpufreq/powernv-cpufreq.c | 39
> ++-
> 1 file changed, 38 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/powernv-cpufreq.c
> b/drivers/cpufreq/powernv-cpufreq.c
> index 2dfd4fd..4837eed 100644
> --- a/drivers/cpufreq/powernv-cpufreq.c
> +++ b/drivers/cpufreq/powernv-cpufreq.c
> @@ -36,7 +36,7 @@
> #define POWERNV_MAX_PSTATES256
>
> static struct cpufreq_frequency_table powernv_freqs[POWERNV_MAX_PSTATES+1];
> -static bool rebooting;
> +static bool rebooting, throttled;
>
> /*
> * Note: The set of pstates consists of contiguous integers, the
> @@ -294,6 +294,40 @@ static inline unsigned int get_nominal_index(void)
> return powernv_pstate_info.max - powernv_pstate_info.nominal;
> }
>
> +static void powernv_cpufreq_throttle_check(unsigned int cpu)
> +{
> + unsigned long pmsr;
> + int pmsr_pmax, pmsr_lp;
> +
> + pmsr = get_pmspr(SPRN_PMSR);
> +
> + /* Check for Pmax Capping */
> + pmsr_pmax = (s8)((pmsr >> 32) & 0xFF);
u8 ?
> + if (pmsr_pmax != powernv_pstate_info.max) {
> + throttled = true;
> + pr_warn("Cpu %d Pmax is reduced to %d\n", cpu, pmsr_pmax);
> + }
> +
> + /* Check for Psafe by reading LocalPstate
> +* or check if Psafe_mode_active- 34th bit is set in PMSR.
> +*/
Proper multi-line comment format is:
/*
*
*/
> + pmsr_lp = (s8)((pmsr >> 48) & 0xFF);
> + if ((pmsr_lp < powernv_pstate_info.min) || ((pmsr >> 30) & 1)) {
> + throttled = true;
> + pr_warn("Cpu %d in Psafe %d PMSR[34]=%lx\n", cpu,
> + pmsr_lp, ((pmsr >> 30) & 1));
> + }
> +
> + /* Check if SPR_EM_DISABLED- 33rd bit is set in PMSR */
> + if ((pmsr >> 31) & 1) {
> + throttled = true;
> + pr_warn("Frequency management disabled cpu %d PMSR[33]=%lx\n",
> + cpu, ((pmsr >> 31) & 1));
> + }
> + if (throttled)
> + pr_warn("Cpu Frequency is throttled\n");
> +}
> +
> /*
> * powernv_cpufreq_target_index: Sets the frequency corresponding to
> * the cpufreq table entry indexed by new_index on the cpus in the
> @@ -307,6 +341,9 @@ static int powernv_cpufreq_target_index(struct
> cpufreq_policy *policy,
> if (unlikely(rebooting) && new_index != get_nominal_index())
> return 0;
>
> + if (!throttled)
> + powernv_cpufreq_throttle_check(smp_processor_id());
And CPU can't come out of throttling again ?
> +
> freq_data.pstate_id = powernv_freqs[new_index].driver_data;
--
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] sched: Improve load balancing in the presence of idle CPUs
Hi Wanpeng On 03/27/2015 07:42 AM, Wanpeng Li wrote: > Hi Preeti, > On Thu, Mar 26, 2015 at 06:32:44PM +0530, Preeti U Murthy wrote: >> >> 1. An ILB CPU was chosen from the first numa domain to trigger nohz idle >> load balancing [Given the experiment, upto 6 CPUs per core could be >> potentially idle in this domain.] >> >> 2. However the ILB CPU would call load_balance() on itself before >> initiating nohz idle load balancing. >> >> 3. Given cores are SMT8, the ILB CPU had enough opportunities to pull >> tasks from its sibling cores to even out load. >> >> 4. Now that the ILB CPU was no longer idle, it would abort nohz idle >> load balancing > > I don't see abort nohz idle load balancing when ILB CPU was no longer idle > in nohz_idle_balance(), could you explain more in details? When the ILB CPU pulls load in rebalance_domains(), its idle state is set to CPU_NOT_IDLE. "" idle = idle_cpu(cpu) ? CPU_IDLE : CPU_NOT_IDLE; And, When nohz_idle_balance() is called, the state of idle of ILB CPU is checked before proceeding with load balancing on idle CPUs. "" if (idle != CPU_IDLE || !test_bit(NOHZ_BALANCE_KICK, nohz_flags(this_cpu))) goto end; You see that nohz idle balancing gets aborted. Regards Preeti U Murthy > > Regards, > Wanpeng Li > -- 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/
linux-next: manual merge of the dt-rh tree with the mips tree
Hi Rob,
Today's linux-next merge of the dt-rh tree got conflicts in
Documentation/devicetree/bindings/mips/brcm/brcm,bcm3384-intc.txt and
Documentation/devicetree/bindings/mips/brcm/brcm,cm-dsl.txt between
commits b43a3ff04e59 ("MIPS: BMIPS: Delete the irqchip driver from
irq.c") and faf18d2dd323 ("MIPS: BMIPS: Update DT bindings to reflect
new SoC support") from the mips tree and commit 23a71fd616bf
("dt-bindings: brcm: rationalize Broadcom documentation naming") from
the dt-rh tree.
I fixed it up (the mips tree commits removed the files) and can carry
the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp7TO2Tz5SGr.pgp
Description: OpenPGP digital signature
Re: [PATCH] xen-blkback: enlarge the array size of blkback name
You are right, roger. Thanks. domid is a u16, it will occupy 5 characters at most. So the biggest length of blkback name is 8+5+5=18. At this situation, define BLKBACK_NAME_LEN macro to be 20 is safe. On 2015/3/26 19:23, Roger Pau Monné wrote: El 13/03/15 a les 16.52, Tao Chen ha escrit: The blkback name is like blkback.domid.xvd[a-z], if domid has three digits (means larger than 100), then the backmost xvd wouldn't be fully shown. Define a BLKBACK_NAME_LEN macro which is (TASK_COMM_LEN * 2), enlarge the array size of blkback name, so it will be fully shown in any case. Signed-off-by: Tao Chen --- drivers/block/xen-blkback/xenbus.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c index e3afe97..0289e21 100644 --- a/drivers/block/xen-blkback/xenbus.c +++ b/drivers/block/xen-blkback/xenbus.c @@ -21,6 +21,9 @@ #include #include "common.h" +/* Enlarge the array size in order to fully show blkback name. */ +#define BLKBACK_NAME_LEN (TASK_COMM_LEN * 2) Any reason to use TASK_COMM_LEN instead of just coding it to 17? Or maybe 20 to be on the safe side? Roger. . -- 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] phy: core: fix registration of built in drivers
Built in PHY drivers probe may run as early as arch_initcall. This is the case
on ARM when device tree is enabled, since of_platform_populate() is called from
customize_machine(). The trouble is that at this stage phy_class is not yet
initialized, and as a result device_add() does not add the newly registered PHY
to the list of class device. This breaks of_phy_simple_xlate().
Move phy_class initialization before arch_initcall to fix this.
Signed-off-by: Baruch Siach
---
drivers/phy/phy-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index a12d35338313..648c3b179459 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -892,7 +892,7 @@ static int __init phy_core_init(void)
return 0;
}
-module_init(phy_core_init);
+postcore_initcall(phy_core_init);
static void __exit phy_core_exit(void)
{
--
2.1.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/
Re: [RFC PATCH 00/11] an introduction of library operating system for Linux (LibOS)
On Fri, Mar 27, 2015 at 4:31 AM, Rusty Russell wrote:
> Richard Weinberger writes:
>> This also infers that arch/lib will be broken most of the time as
>> every time the networking stack references a new symbol it
>> has to be duplicated into arch/lib.
>>
>> But this does not mean that your idea is bad, all I want to say that
>> I'm not sure whether arch/lib is the right approach.
>> Maybe Arnd has a better idea.
>
> Exactly why I look forward to getting this in-tree. Jeremy Kerr and I
> wrote nfsim back in 2005(!) which stubbed around the netfilter
> infrastructure; with failtest and valgrind it found some nasty bugs. It
> was too much hassle to maintain out-of-tree though :(
>
> I look forward to a flood of great bugfixes from this work :)
IIRC, the ability to run UML under valgrind was also one of its key features?
And that's not limited to networking.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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: Kernel warning at fs/btrfs/inode.c:8693 btrfs_destroy_inode+0x1fa/0x2a0 [btrfs]()
On Thu, Mar 26, 2015 at 9:39 PM, Nikolaus Rath wrote: > Thanks. Does this mean that I risk data corruption when using btrfs with > 4.0-rc3, or is this relatively harmless? I can't answer that. I'd say use 3.18.9 or 3.19.2 if you want reduced risk of corruption, or use the current week's rc (which is rc5) if you can accept a bit more risk for testing purposes. -- Chris Murphy -- 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] hpfs: hpfs_error: Remove static buffer, use vsprintf extension %pV instead
Removing unnecessary static buffers is good.
Use the vsprintf %pV extension instead.
Signed-off-by: Joe Perches
---
fs/hpfs/super.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/fs/hpfs/super.c b/fs/hpfs/super.c
index 7cd00d3..f445d15 100644
--- a/fs/hpfs/super.c
+++ b/fs/hpfs/super.c
@@ -52,17 +52,20 @@ static void unmark_dirty(struct super_block *s)
}
/* Filesystem error... */
-static char err_buf[1024];
-
void hpfs_error(struct super_block *s, const char *fmt, ...)
{
+ struct va_format vaf;
va_list args;
va_start(args, fmt);
- vsnprintf(err_buf, sizeof(err_buf), fmt, args);
+
+ vaf.fmt = fmt;
+ vaf.va =
+
+ pr_err("filesystem error: %pV", );
+
va_end(args);
- pr_err("filesystem error: %s", err_buf);
if (!hpfs_sb(s)->sb_was_error) {
if (hpfs_sb(s)->sb_err == 2) {
pr_cont("; crashing the system because you wanted
it\n");
--
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 00/11] an introduction of library operating system for Linux (LibOS)
Richard Weinberger writes: > This also infers that arch/lib will be broken most of the time as > every time the networking stack references a new symbol it > has to be duplicated into arch/lib. > > But this does not mean that your idea is bad, all I want to say that > I'm not sure whether arch/lib is the right approach. > Maybe Arnd has a better idea. Exactly why I look forward to getting this in-tree. Jeremy Kerr and I wrote nfsim back in 2005(!) which stubbed around the netfilter infrastructure; with failtest and valgrind it found some nasty bugs. It was too much hassle to maintain out-of-tree though :( I look forward to a flood of great bugfixes from this work :) Cheers, 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/
Re: Kernel warning at fs/btrfs/inode.c:8693 btrfs_destroy_inode+0x1fa/0x2a0 [btrfs]()
On Mar 26 2015, Chris Murphy wrote: > On Thu, Mar 26, 2015 at 6:38 PM, Nikolaus Rath wrote: > >> I'm running 4.0-rc3, and I'm regularly getting these warnings in my >> kernel log: > >> Mar 26 17:31:13 vostro kernel: [21480.088682] WARNING: CPU: 0 PID: >> 28958 at fs/btrfs/inode.c:8693 btrfs_destroy_inode+0x1fa/0x2a0 >> [btrfs]() > > It's known. > https://lkml.org/lkml/2015/3/7/41 Thanks. Does this mean that I risk data corruption when using btrfs with 4.0-rc3, or is this relatively harmless? Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- 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 v7 0/5] vfs: Non-blockling buffered fs read (page cache only)
On Mon, 16 Mar 2015 14:27:10 -0400 Milosz Tanski wrote: > This patchset introduces two new syscalls preadv2 and pwritev2. They are the > same syscalls as preadv and pwrite but with a flag argument. Additionally, > preadv2 implements an extra RWF_NONBLOCK flag. I still don't understand why pwritev() exists. We discussed this last time but it seems nothing has changed. I'm not seeing here an adequate description of why it exists nor a justification for its addition. Also, why are we adding new syscalls instead of using O_NONBLOCK? I think this might have been discussed before, but the changelogs haven't been updated to reflect it - please do so. > The RWF_NONBLOCK flag in preadv2 introduces an ability to perform a > non-blocking read from regular files in buffered IO mode. This works by only > for those filesystems that have data in the page cache. > > We discussed these changes at this year's LSF/MM summit in Boston. More > details > on the Samba use case, the numbers, and presentation is available at this > link: > https://lists.samba.org/archive/samba-technical/2015-March/106290.html https://drive.google.com/file/d/0B3maCn0jCvYncndGbXJKbGlhejQ/view?usp=sharing talks about "sync" but I can't find a description of what this actually is. It appears to perform better than anything else? > Background: > > Using a threadpool to emulate non-blocking operations on regular buffered > files is a common pattern today (samba, libuv, etc...) Applications split the > work between network bound threads (epoll) and IO threadpool. Not every > application can use sendfile syscall (TLS / post-processing). > > This common pattern leads to increased request latency. Latency can be due to > additional synchronization between the threads or fast (cached data) request > stuck behind slow request (large / uncached data). > > The preadv2 syscall with RWF_NONBLOCK lets userspace applications bypass > enqueuing operation in the threadpool if it's already available in the > pagecache. A thing which bugs me about pread2() is that it is specifically tailored to applications which are able to use a partial read result. ie, by sending it over the network. But it is not very useful for the class of applications which require that the entire read be completed before they can proceed with using the data. Such applications will have to run pread2(), see the short result, save away the partial data, perform some IO then fetch the remaining data then proceed. By this time, the original partially read data may have fallen out of CPU cache (or we're on a different CPU) and the data will need to be fetched into cache a second time. Such applications would be better served if they were able to query for pagecache presence _before_ doing the big copy_to_user(), so they can ensure that all the data is in pagecache before copying it in. ie: fincore(), perhaps supported by a synchronous POSIX_FADV_WILLNEED. And of course fincore could be used by Samba etc to avoid blocking on reads. It wouldn't perform quite as well as pread2(), but I bet it's good enough. Bottom line: with pread2() there's still a need for fincore(), but with fincore() there probably isn't a need for pread2(). And (again) we've discussed this before, but the patchset gets resent as if nothing had happened. And I'm doubtful about claims that it absolutely has to be non-blocking 100% of the time. I bet that 99.99% is good enough. A fincore() option to run mark_page_accessed() against present pages would help with the race-with-reclaim situation. -- 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: Kernel warning at fs/btrfs/inode.c:8693 btrfs_destroy_inode+0x1fa/0x2a0 [btrfs]()
On Thu, Mar 26, 2015 at 6:38 PM, Nikolaus Rath wrote: > I'm running 4.0-rc3, and I'm regularly getting these warnings in my > kernel log: > Mar 26 17:31:13 vostro kernel: [21480.088682] WARNING: CPU: 0 PID: 28958 at > fs/btrfs/inode.c:8693 btrfs_destroy_inode+0x1fa/0x2a0 [btrfs]() It's known. https://lkml.org/lkml/2015/3/7/41 -- Chris Murphy -- 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 v5] Add virtio-input driver.
"Michael S. Tsirkin" writes: > On Thu, Mar 26, 2015 at 11:49:25AM +0100, Gerd Hoffmann wrote: >> virtio-input is basically evdev-events-over-virtio, so this driver isn't >> much more than reading configuration from config space and forwarding >> incoming events to the linux input layer. >> >> Signed-off-by: Gerd Hoffmann > > Still a bit worried about using input.h as host/guest > interface (can't we use some formal standard, e.g. USB HID?), > but I'll let Rusty decide that. I like the simplicity, and this API is pretty well proven. Since this is under drivers/virtio rather than drivers/input, I've applied it to my tree. I have a dream where Denys Vlasenko adds this and the virtio gl device to lguest, and we have X running under lguest :) Applied! 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/
Re: [PATCH] leds-gpio: Fix error handling and memory leak
On 03/26/2015 08:20 PM, Bryan Wu wrote:
> On Mon, Mar 9, 2015 at 5:43 PM, wrote:
>> From: Corey Minyard
>>
>> The leds-gpio driver would not clean up properly if it failed in some
>> places, and it wasn't freeing its private data.
>>
>> Signed-off-by: Corey Minyard
>> ---
>> drivers/leds/leds-gpio.c | 13 +
>> 1 file changed, 9 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
>> index d26af0a..32f7642 100644
>> --- a/drivers/leds/leds-gpio.c
>> +++ b/drivers/leds/leds-gpio.c
>> @@ -198,8 +198,10 @@ static struct gpio_leds_priv *gpio_leds_create(struct
>> platform_device *pdev)
>> } else {
>> if (IS_ENABLED(CONFIG_OF) && !led.name && np)
>> led.name = np->name;
>> - if (!led.name)
>> - return ERR_PTR(-EINVAL);
>> + if (!led.name) {
>> + ret = -EINVAL;
>> + goto err;
>> + }
>> }
>> fwnode_property_read_string(child, "linux,default-trigger",
>> _trigger);
>> @@ -217,19 +219,21 @@ static struct gpio_leds_priv *gpio_leds_create(struct
>> platform_device *pdev)
>> if (fwnode_property_present(child, "retain-state-suspended"))
>> led.retain_state_suspended = 1;
>>
>> - ret = create_gpio_led(, >leds[priv->num_leds++],
>> + ret = create_gpio_led(, >leds[priv->num_leds],
> Why need this change? it's correct. And your add one more line
> "priv->num_leds++"
That's actually the major source of the problem. The value of
priv->num_leds was not correct if it failed before this point, and there
was already one "goto err" above this code and I added another to
properly handle not allocating the led name. If it failed there it
would leave an LED lying around but free the memory underneath it. So
instead, modify the failure recovery code to be priv->num_leds-1 instead
of priv->num_leds-2 and don't increment priv->num_leds until you have
success.
>> dev, NULL);
>> if (ret < 0) {
>> fwnode_handle_put(child);
>> goto err;
>> }
>> + priv->num_leds++;
> Why need this?
See above.
>> }
>>
>> return priv;
>>
>> err:
>> - for (count = priv->num_leds - 2; count >= 0; count--)
>> + for (count = priv->num_leds - 1; count >= 0; count--)
>> delete_gpio_led(>leds[count]);
>> + devm_kfree(dev, priv);
> priv is created by devm_kzalloc(), so if driver probing return error,
> it will be freed automatically, you don't need call devm_free();
Ah, ok. Then this is unnecessary. Do want a new patch?
Thanks,
-corey
>> return ERR_PTR(ret);
>> }
>>
>> @@ -283,6 +287,7 @@ static int gpio_led_remove(struct platform_device *pdev)
>>
>> for (i = 0; i < priv->num_leds; i++)
>> delete_gpio_led(>leds[i]);
>> + devm_kfree(>dev, priv);
> No need this during remove.
>
>> return 0;
>> }
>> --
>> 1.8.3.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-leds" 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 1/2] ocfs2: Logging: Remove static buffer, use vsprintf extension %pV
Use the vsprintf %pV extension to avoid using a static buffer
and remove the now unnecessary buffer.
Signed-off-by: Joe Perches
---
fs/ocfs2/super.c | 34 +++---
1 file changed, 19 insertions(+), 15 deletions(-)
diff --git a/fs/ocfs2/super.c b/fs/ocfs2/super.c
index 2dfaa5c..3ee15b3 100644
--- a/fs/ocfs2/super.c
+++ b/fs/ocfs2/super.c
@@ -2593,22 +2593,23 @@ static int ocfs2_handle_error(struct super_block *sb)
}
-static char error_buf[1024];
-
-int __ocfs2_error(struct super_block *sb,
- const char *function,
- const char *fmt, ...)
+int __ocfs2_error(struct super_block *sb, const char *function,
+ const char *fmt, ...)
{
+ struct va_format vaf;
va_list args;
va_start(args, fmt);
- vsnprintf(error_buf, sizeof(error_buf), fmt, args);
- va_end(args);
+
+ vaf.fmt = fmt;
+ vaf.va =
/* Not using mlog here because we want to show the actual
* function the error came from. */
- printk(KERN_CRIT "OCFS2: ERROR (device %s): %s: %s\n",
- sb->s_id, function, error_buf);
+ printk(KERN_CRIT "OCFS2: ERROR (device %s): %s: %pV\n",
+ sb->s_id, function, );
+
+ va_end(args);
return ocfs2_handle_error(sb);
}
@@ -2616,18 +2617,21 @@ int __ocfs2_error(struct super_block *sb,
/* Handle critical errors. This is intentionally more drastic than
* ocfs2_handle_error, so we only use for things like journal errors,
* etc. */
-void __ocfs2_abort(struct super_block* sb,
- const char *function,
+void __ocfs2_abort(struct super_block *sb, const char *function,
const char *fmt, ...)
{
+ struct va_format vaf;
va_list args;
va_start(args, fmt);
- vsnprintf(error_buf, sizeof(error_buf), fmt, args);
- va_end(args);
- printk(KERN_CRIT "OCFS2: abort (device %s): %s: %s\n",
- sb->s_id, function, error_buf);
+ vaf.fmt = fmt;
+ vaf.va =
+
+ printk(KERN_CRIT "OCFS2: abort (device %s): %s: %pV\n",
+ sb->s_id, function, );
+
+ va_end(args);
/* We don't have the cluster support yet to go straight to
* hard readonly in here. Until then, we want to keep
--
2.1.2
--
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/2] ocfs2: Neaten do_error, ocfs2_error and ocfs2_abort
These uses sometimes do and sometimes don't have '\n' terminations.
Make the uses consistently use '\n' terminations and remove the
newline from the functions.
Miscellanea:
o Coalesce formats
o Realign arguments
Signed-off-by: Joe Perches
---
fs/ocfs2/alloc.c| 90 +++--
fs/ocfs2/aops.c | 4 +--
fs/ocfs2/dir.c | 49 +--
fs/ocfs2/extent_map.c | 22 ++--
fs/ocfs2/inode.c| 18 +-
fs/ocfs2/journal.c | 2 +-
fs/ocfs2/localalloc.c | 3 +-
fs/ocfs2/move_extents.c | 5 ++-
fs/ocfs2/quota_local.c | 3 +-
fs/ocfs2/refcounttree.c | 53 +
fs/ocfs2/suballoc.c | 75 +++--
fs/ocfs2/super.c| 4 +--
fs/ocfs2/super.h| 6 ++--
fs/ocfs2/xattr.c| 35 +--
14 files changed, 165 insertions(+), 204 deletions(-)
diff --git a/fs/ocfs2/alloc.c b/fs/ocfs2/alloc.c
index 2b0aaa6..5483f0b 100644
--- a/fs/ocfs2/alloc.c
+++ b/fs/ocfs2/alloc.c
@@ -909,27 +909,25 @@ static int ocfs2_validate_extent_block(struct super_block
*sb,
if (!OCFS2_IS_VALID_EXTENT_BLOCK(eb)) {
rc = ocfs2_error(sb,
- "Extent block #%llu has bad signature %.*s",
- (unsigned long long)bh->b_blocknr, 7,
- eb->h_signature);
+"Extent block #%llu has bad signature %.*s\n",
+(unsigned long long)bh->b_blocknr, 7,
+eb->h_signature);
goto bail;
}
if (le64_to_cpu(eb->h_blkno) != bh->b_blocknr) {
rc = ocfs2_error(sb,
- "Extent block #%llu has an invalid h_blkno "
- "of %llu",
- (unsigned long long)bh->b_blocknr,
- (unsigned long long)le64_to_cpu(eb->h_blkno));
+"Extent block #%llu has an invalid h_blkno of
%llu\n",
+(unsigned long long)bh->b_blocknr,
+(unsigned long long)le64_to_cpu(eb->h_blkno));
goto bail;
}
if (le32_to_cpu(eb->h_fs_generation) != OCFS2_SB(sb)->fs_generation) {
rc = ocfs2_error(sb,
- "Extent block #%llu has an invalid "
- "h_fs_generation of #%u",
- (unsigned long long)bh->b_blocknr,
- le32_to_cpu(eb->h_fs_generation));
+"Extent block #%llu has an invalid
h_fs_generation of #%u\n",
+(unsigned long long)bh->b_blocknr,
+le32_to_cpu(eb->h_fs_generation));
goto bail;
}
bail:
@@ -1446,8 +1444,7 @@ static int ocfs2_find_branch_target(struct
ocfs2_extent_tree *et,
while(le16_to_cpu(el->l_tree_depth) > 1) {
if (le16_to_cpu(el->l_next_free_rec) == 0) {
ocfs2_error(ocfs2_metadata_cache_get_super(et->et_ci),
- "Owner %llu has empty "
- "extent list (next_free_rec == 0)",
+ "Owner %llu has empty extent list
(next_free_rec == 0)\n",
(unsigned long
long)ocfs2_metadata_cache_owner(et->et_ci));
status = -EIO;
goto bail;
@@ -1456,9 +1453,7 @@ static int ocfs2_find_branch_target(struct
ocfs2_extent_tree *et,
blkno = le64_to_cpu(el->l_recs[i].e_blkno);
if (!blkno) {
ocfs2_error(ocfs2_metadata_cache_get_super(et->et_ci),
- "Owner %llu has extent "
- "list where extent # %d has no physical "
- "block start",
+ "Owner %llu has extent list where extent #
%d has no physical block start\n",
(unsigned long
long)ocfs2_metadata_cache_owner(et->et_ci), i);
status = -EIO;
goto bail;
@@ -1788,8 +1783,7 @@ static int __ocfs2_find_path(struct ocfs2_caching_info
*ci,
while (el->l_tree_depth) {
if (le16_to_cpu(el->l_next_free_rec) == 0) {
ocfs2_error(ocfs2_metadata_cache_get_super(ci),
- "Owner %llu has empty extent list at "
- "depth %u\n",
+ "Owner %llu has empty extent list at depth
%u\n",
(unsigned long
long)ocfs2_metadata_cache_owner(ci),
le16_to_cpu(el->l_tree_depth));
ret = -EROFS;
[PATCH 0/2] ocfs2: logging neatening
Joe Perches (2): ocfs2: Logging: Remove static buffer, use vsprintf extension %pV ocfs2: Neaten do_error, ocfs2_error and ocfs2_abort fs/ocfs2/alloc.c| 90 +++-- fs/ocfs2/aops.c | 4 +-- fs/ocfs2/dir.c | 49 +-- fs/ocfs2/extent_map.c | 22 ++-- fs/ocfs2/inode.c| 18 +- fs/ocfs2/journal.c | 2 +- fs/ocfs2/localalloc.c | 3 +- fs/ocfs2/move_extents.c | 5 ++- fs/ocfs2/quota_local.c | 3 +- fs/ocfs2/refcounttree.c | 53 + fs/ocfs2/suballoc.c | 75 +++-- fs/ocfs2/super.c| 34 ++- fs/ocfs2/super.h| 6 ++-- fs/ocfs2/xattr.c| 35 +-- 14 files changed, 182 insertions(+), 217 deletions(-) -- 2.1.2 -- 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 04/13] thermal: Fix not emulating critical temperatures
Hi Sascha,
On Thu, Mar 26, 2015 at 9:23 PM, Sascha Hauer wrote:
> commit e6e238c38 (thermal: sysfs: Add a new sysfs node emul_temp for
> thermal emulation) promised not to emulate critical temperatures,
> but the check for critical temperatures is broken in multiple ways:
>
> - The code should only accept an emulated temperature when the emulated
> temperature is lower than the critical temperature. Instead the code
> accepts an emulated temperature whenever the real temperature is lower
> than the critical temperature. This makes no sense and trying to
> emulate a temperature higher than the critical temperature halts the
> system.
Even higher than critical temperature should be accepted. see my
further comments below.
> - When trying to emulate a higher-than-critical temperature we should either
> limit the emulated temperature to the maximum non critical temperature
> or refuse to emulate this temperature. Instead the code just silently
> ignores the emulated temperature and continues with the real temperature.
>
> This patch moves the test for illegal emulated temperature to the sysfs
> write function so that we can properly refuse illegal temperatures here.
> Trying to write illegal temperatures results in an error message. While
> at it use IS_ENABLED() instead of #ifdefs.
>
> Signed-off-by: Sascha Hauer
> ---
> drivers/thermal/thermal_core.c | 46
> ++
> 1 file changed, 24 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index dcea909..ebca854 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -414,11 +414,6 @@ static void handle_thermal_trip(struct
> thermal_zone_device *tz, int trip)
> int thermal_zone_get_temp(struct thermal_zone_device *tz, unsigned long
> *temp)
> {
> int ret = -EINVAL;
> -#ifdef CONFIG_THERMAL_EMULATION
> - int count;
> - unsigned long crit_temp = -1UL;
> - enum thermal_trip_type type;
> -#endif
>
> if (!tz || IS_ERR(tz) || !tz->ops->get_temp)
> goto exit;
> @@ -426,25 +421,10 @@ int thermal_zone_get_temp(struct thermal_zone_device
> *tz, unsigned long *temp)
> mutex_lock(>lock);
>
> ret = tz->ops->get_temp(tz, temp);
> -#ifdef CONFIG_THERMAL_EMULATION
> - if (!tz->emul_temperature)
> - goto skip_emul;
> -
> - for (count = 0; count < tz->trips; count++) {
> - ret = tz->ops->get_trip_type(tz, count, );
> - if (!ret && type == THERMAL_TRIP_CRITICAL) {
> - ret = tz->ops->get_trip_temp(tz, count, _temp);
> - break;
> - }
> - }
> -
> - if (ret)
> - goto skip_emul;
>
> - if (*temp < crit_temp)
I guess this check is confusing. Actually instead of returning
emulating temperature it is returning actual temperature. But the
important thing to look here is that actual temperature is higher than
critical temperature. So this check prevents the user from suppressing
the critical temperature and hence prevents from burning up the chip.
> + if (IS_ENABLED(CONFIG_THERMAL_EMULATION) && tz->emul_temperature)
> *temp = tz->emul_temperature;
> -skip_emul:
> -#endif
> +
> mutex_unlock(>lock);
> exit:
> return ret;
> @@ -788,10 +768,32 @@ emul_temp_store(struct device *dev, struct
> device_attribute *attr,
> struct thermal_zone_device *tz = to_thermal_zone(dev);
> int ret = 0;
> unsigned long temperature;
> + int trip;
> + unsigned long crit_temp;
> + enum thermal_trip_type type;
>
> if (kstrtoul(buf, 10, ))
> return -EINVAL;
>
> + for (trip = 0; trip < tz->trips; trip++) {
> + ret = tz->ops->get_trip_type(tz, trip, );
> + if (ret)
> + return ret;
> +
> + if (type != THERMAL_TRIP_CRITICAL)
> + continue;
> +
> + ret = tz->ops->get_trip_temp(tz, trip, _temp);
> + if (ret)
> + return ret;
> +
> + if (temperature >= crit_temp) {
> + dev_err(>device, "Will not emulate critical
> temperature %luC (tcrit=%luC)\n",
> + temperature / 1000, crit_temp / 1000);
> + return -EINVAL;
> + }
Emulating critical temperature is very much needed.
> + }
> +
> if (!tz->ops->set_emul_temp) {
> mutex_lock(>lock);
> tz->emul_temperature = temperature;
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" 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
Re: [PATCH] [RESEND][TRIVIAL] treewide: fix occurrences of "the the "
On 03/26/2015 07:23 PM, Joe Perches wrote: > On Thu, 2015-03-26 at 18:55 -0700, Michael Opdenacker wrote: >> Fix all occurrences of "the the ", and occasionally "in in ", >> in the source code, comments and documentation. > [] > >> arch/powerpc/mm/gup.c | 235 >> + > I think that one snuck in unintentionally. Oops, I should look better next time. This one was quite obvious. Many thanks! Michael. -- Michael Opdenacker, CEO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com +33 484 258 098 -- 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 RESEND] tty/n_gsm.c: fix a memory leak when gsmtty is removed
when gsmtty_remove put dlci, it will cause memory leak if dlci->port's refcount
is zero.
So we do the cleanup work in .cleanup callback instead.
dlci will be last put in two call chains.
1) gsmld_close -> gsm_cleanup_mux -> gsm_dlci_release -> dlci_put
2) gsmld_remove -> dlci_put
so there is a race. the memory leak depends on the race.
In call chain 2. we hit the memory leak. below comment tells.
release_tty -> tty_driver_remove_tty -> gsmtty_remove -> dlci_put ->
tty_port_destructor (WARN_ON(port->itty) and return directly)
|
tty->port->itty = NULL;
|
tty_kref_put ---> release_one_tty -> gsmtty_cleanup (added by
our patch)
So our patch fix the memory leak by doing the cleanup work after tty core did.
Signed-off-by: Pan Xinhui
---
Changes in v2:
Don't use schedule_work to put dlci. Replace .remove with .cleanup callback.
drivers/tty/n_gsm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index c434376..bce16e4 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -3170,7 +3170,7 @@ static int gsmtty_break_ctl(struct tty_struct *tty, int
state)
return gsmtty_modem_update(dlci, encode);
}
-static void gsmtty_remove(struct tty_driver *driver, struct tty_struct *tty)
+static void gsmtty_cleanup(struct tty_struct *tty)
{
struct gsm_dlci *dlci = tty->driver_data;
struct gsm_mux *gsm = dlci->gsm;
@@ -3178,7 +3178,6 @@ static void gsmtty_remove(struct tty_driver *driver,
struct tty_struct *tty)
dlci_put(dlci);
dlci_put(gsm->dlci[0]);
mux_put(gsm);
- driver->ttys[tty->index] = NULL;
}
/* Virtual ttys for the demux */
@@ -3199,7 +3198,7 @@ static const struct tty_operations gsmtty_ops = {
.tiocmget = gsmtty_tiocmget,
.tiocmset = gsmtty_tiocmset,
.break_ctl = gsmtty_break_ctl,
- .remove = gsmtty_remove,
+ .cleanup= gsmtty_cleanup,
};
--
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: [withdrawn] zsmalloc-remove-extra-cond_resched-in-__zs_compact.patch removed from -mm tree
On Thu, Mar 26, 2015 at 05:13:13PM +0900, Sergey Senozhatsky wrote:
> On (03/26/15 16:39), Minchan Kim wrote:
> > Hello Sergey,
> >
> > Sorry for slow response.
> > I am overwhelmed with too much to do. :(
> >
>
> Hello,
> sure, no problem.
>
> > > > diff -puN
> > > > mm/zsmalloc.c~zsmalloc-remove-extra-cond_resched-in-__zs_compact
> > > > mm/zsmalloc.c
> > > > --- a/mm/zsmalloc.c~zsmalloc-remove-extra-cond_resched-in-__zs_compact
> > > > +++ a/mm/zsmalloc.c
> > > > @@ -1717,8 +1717,6 @@ static unsigned long __zs_compact(struct
> > > > struct page *dst_page = NULL;
> > > > unsigned long nr_total_migrated = 0;
> > > >
> > > > - cond_resched();
> > > > -
> > > > spin_lock(>lock);
> > > > while ((src_page = isolate_source_page(class))) {
>
> >
> > If we removed cond_resched out of outer loop(ie, your patch), we lose
> > the chance to reschedule if alloc_target_page fails(ie, there is no
> > zspage in ZS_ALMOST_FULL and ZS_ALMOST_EMPTY).
>
>
> in outer loop we have preemption enabled and unlocked class. wouldn't that
> help?
> (hm, UP system?)
It depends on preemption model. If you enable full preemption, you are right
but if you enable just voluntary preemption, cond_resched will help latency.
Thanks.
--
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/
Re: [PATCH v8 10/30] PCI: Introduce pci_host_bridge_list to manage host bridges
On 2015/3/27 0:31, Yinghai Lu wrote: > On Mon, Mar 23, 2015 at 8:34 PM, Yijing Wang wrote: >> Introduce pci_host_bridge_list to manage pci host >> bridges in system, this make us have the ability >> to check whether the new host would conflict with >> existing one. Then we could remove bus alreay exist >> check in __pci_create_root_bus(). > > Can we use bus_type instead? > Then we can use bus_find_device for the host_bridge enumeration. > > Please refer the patches that I sent out couple years ago. HI Yinghai, I think your changes is good, but in this series, we only iterate the pci_host_bridge in drivers/pci/host-bridge.c. The simple list is enough, of course, if we want to export this list and support to host bridge hotplug, we must need a new iteration for host bridge, and your series looks good to me, I read your series history, found Bjorn comment a lot. So I think Bjorn may have some comments for this. Thanks! Yijing. -- Thanks! Yijing -- 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] sched: Improve load balancing in the presence of idle CPUs
Hi Preeti, On Thu, Mar 26, 2015 at 06:32:44PM +0530, Preeti U Murthy wrote: > >1. An ILB CPU was chosen from the first numa domain to trigger nohz idle >load balancing [Given the experiment, upto 6 CPUs per core could be >potentially idle in this domain.] > >2. However the ILB CPU would call load_balance() on itself before >initiating nohz idle load balancing. > >3. Given cores are SMT8, the ILB CPU had enough opportunities to pull >tasks from its sibling cores to even out load. > >4. Now that the ILB CPU was no longer idle, it would abort nohz idle >load balancing I don't see abort nohz idle load balancing when ILB CPU was no longer idle in nohz_idle_balance(), could you explain more in details? Regards, Wanpeng Li -- 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 v7 0/5] vfs: Non-blockling buffered fs read (page cache only)
On Thu, Mar 26, 2015 at 3:12 PM, Milosz Tanski wrote: > On Thu, Mar 26, 2015 at 7:55 AM, Christoph Hellwig wrote: >> >> On Mon, Mar 16, 2015 at 02:27:10PM -0400, Milosz Tanski wrote: >> > This patchset introduces two new syscalls preadv2 and pwritev2. They are >> > the >> > same syscalls as preadv and pwrite but with a flag argument. Additionally, >> > preadv2 implements an extra RWF_NONBLOCK flag. >> >> There was some arugment that we just don't wait and don't have the >> classic unix "blocking" semantics. Maybe it's time to bite the bullet >> and rename it to RWF_DONTWAIT? (I personally dont really care). > > > Sure. It is in line with the MSG_DONTWAIT flag for sendmsg() which > this whole idea is based on anyways. Okay, It's RWF_DONTWAIT now. I also split it into two RWF_DONTWAIT for the userspace API and IOCB_DONTWAIT that goes into kiocb->ki_flags. > >> >> >> Second this probably needs to be on top of Al's for-next tree: >> >> >> https://git.kernel.org/cgit/linux/kernel/git/viro/vfs.git/log/?h=for-next >> >> Note that this has a flags field in struct kiocb, so we could just use >> that for the flags. > > > Okay I started rebasing the patches on-top of that. I did see that > there is a new flags field "ki_flags". I see that there's already a > IOCB_EVENTFD flag. > > Did you see you Andres' question about making the flags a enum? I > usually wouldn't do that, because C++ is stronger when it comes enums, > you can't combine them then assignment them to an enum without a cast. > But in the kernel this doesn't matter. > >> >> >> Otherwise this version look fine to me, let's get it merged! >> >> Al, are yo ready to pick this up? I'd hate to miss another merge >> window. > > > Just got back from vacation today, I'll try to get this out before the > end of the week. I also have to make some adjustments to xfs-tests (to > push preadv2 into xfs_io). You'll see the patches and the pull request against viro/for-next branch tomorrow. The rebase was a bit of work since you guys changed a fair amount of stuff. > > > -- > Milosz Tanski > CTO > 16 East 34th Street, 15th floor > New York, NY 10016 > > p: 646-253-9055 > e: mil...@adfin.com P.S: Sorry for the double email / HTML spam. I'm not a my primary computer and apparently gmail randomly forgets that a thread is plain text only. Thanks gmail. -- Milosz Tanski CTO 16 East 34th Street, 15th floor New York, NY 10016 p: 646-253-9055 e: mil...@adfin.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] [RESEND][TRIVIAL] treewide: fix occurrences of "the the "
On Thu, 2015-03-26 at 18:55 -0700, Michael Opdenacker wrote: > Fix all occurrences of "the the ", and occasionally "in in ", > in the source code, comments and documentation. [] > arch/powerpc/mm/gup.c | 235 > + I think that one snuck in unintentionally. -- 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/7] perf kmem: Print gfp flags in human readable string
Save libtraceevent output and print it in the header.
# perf kmem stat --page --caller
# GFP flags
# -
# 0010: NI: GFP_NOIO
# 00d0:K: GFP_KERNEL
# 0200: NWR: GFP_NOWARN
# 84d0:K|R|Z: GFP_KERNEL|GFP_REPEAT|GFP_ZERO
# 000200d2: HU: GFP_HIGHUSER
# 000200da: HUM: GFP_HIGHUSER_MOVABLE
# 000280da:HUM|Z: GFP_HIGHUSER_MOVABLE|GFP_ZERO
# 002084d0: K|R|Z|NT: GFP_KERNEL|GFP_REPEAT|GFP_ZERO|GFP_NOTRACK
# 0102005a: NF|HW|M: GFP_NOFS|GFP_HARDWALL|GFP_MOVABLE
-
Total alloc (KB) | Hits | Order | Migration type | GFP flags | Callsite
-
60 |15 | 0 | UNMOVABLE | K|R|Z|NT |
pte_alloc_one
40 |10 | 0 |MOVABLE | HUM|Z |
handle_mm_fault
24 | 6 | 0 |MOVABLE | HUM |
do_wp_page
24 | 6 | 0 | UNMOVABLE | K |
__pollwait
...
Requested-by: Joonsoo Kim
Suggested-by: Minchan Kim
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-kmem.c | 221 +++---
1 file changed, 208 insertions(+), 13 deletions(-)
diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index 863d882d6a94..0046e8cebed5 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf/builtin-kmem.c
@@ -545,6 +545,176 @@ static bool valid_page(u64 pfn_or_page)
return true;
}
+struct gfp_flag {
+ unsigned int flags;
+ char *compact_str;
+ char *human_readable;
+};
+
+static struct gfp_flag *gfps;
+static int nr_gfps;
+
+static int gfpcmp(const void *a, const void *b)
+{
+ const struct gfp_flag *fa = a;
+ const struct gfp_flag *fb = b;
+
+ return fa->flags - fb->flags;
+}
+
+/* see include/trace/events/gfpflags.h */
+static const struct {
+ const char *original;
+ const char *compact;
+} gfp_compact_table[] = {
+ { "GFP_TRANSHUGE", "THP" },
+ { "GFP_HIGHUSER_MOVABLE", "HUM" },
+ { "GFP_HIGHUSER", "HU" },
+ { "GFP_USER", "U" },
+ { "GFP_TEMPORARY", "TMP" },
+ { "GFP_KERNEL", "K" },
+ { "GFP_NOFS", "NF" },
+ { "GFP_ATOMIC", "A" },
+ { "GFP_NOIO", "NI" },
+ { "GFP_HIGH", "H" },
+ { "GFP_WAIT", "W" },
+ { "GFP_IO", "I" },
+ { "GFP_COLD", "CO" },
+ { "GFP_NOWARN", "NWR" },
+ { "GFP_REPEAT", "R" },
+ { "GFP_NOFAIL", "NF" },
+ { "GFP_NORETRY","NR" },
+ { "GFP_COMP", "C" },
+ { "GFP_ZERO", "Z" },
+ { "GFP_NOMEMALLOC", "NMA" },
+ { "GFP_MEMALLOC", "MA" },
+ { "GFP_HARDWALL", "HW" },
+ { "GFP_THISNODE", "TN" },
+ { "GFP_RECLAIMABLE","RC" },
+ { "GFP_MOVABLE","M" },
+ { "GFP_NOTRACK","NT" },
+ { "GFP_NO_KSWAPD", "NK" },
+ { "GFP_OTHER_NODE", "ON" },
+ { "GFP_NOWAIT", "NW" },
+};
+
+static size_t max_gfp_len;
+
+static char *compact_gfp_flags(char *gfp_flags)
+{
+ char *orig_flags = strdup(gfp_flags);
+ char *new_flags = NULL;
+ char *str, *pos;
+ size_t len = 0;
+
+ if (orig_flags == NULL)
+ return NULL;
+
+ str = strtok_r(orig_flags, "|", );
+ while (str) {
+ size_t i;
+ char *new;
+ const char *cpt;
+
+ for (i = 0; i < ARRAY_SIZE(gfp_compact_table); i++) {
+ if (strcmp(gfp_compact_table[i].original, str))
+ continue;
+
+ cpt = gfp_compact_table[i].compact;
+ new = realloc(new_flags, len + strlen(cpt) + 2);
+ if (new == NULL) {
+ free(new_flags);
+ return NULL;
+ }
+
+ new_flags = new;
+
+ if (!len) {
+ strcpy(new_flags, cpt);
+ } else {
+ strcat(new_flags, "|");
+ strcat(new_flags, cpt);
+ len++;
+ }
+
+ len += strlen(cpt);
+ }
+
+ str = strtok_r(NULL, "|", );
+ }
+
+ if (max_gfp_len < len)
+ max_gfp_len = len;
+
+
[PATCH 7/7] perf kmem: Add kmem.default config option
Currently perf kmem command will select --slab if neither --slab nor
--page is given for backward compatibility. Add kmem.default config
option to select the default value ('page' or 'slab').
# cat ~/.perfconfig
[kmem]
default = page
# perf kmem stat
SUMMARY (page allocator)
Total allocation requests :1,518 [6,096 KB ]
Total free requests :1,431 [5,748 KB ]
Total alloc+freed requests:1,330 [5,344 KB ]
Total alloc-only requests : 188 [ 752 KB ]
Total free-only requests : 101 [ 404 KB ]
Total allocation failures :0 [0 KB ]
...
Cc: Taeung Song
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-kmem.c | 32 +---
1 file changed, 29 insertions(+), 3 deletions(-)
diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index 0046e8cebed5..5b29cbecf37b 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf/builtin-kmem.c
@@ -28,6 +28,10 @@ static int kmem_slab;
static int kmem_page;
static longkmem_page_size;
+static enum {
+ KMEM_SLAB,
+ KMEM_PAGE,
+} kmem_default = KMEM_SLAB; /* for backward compatibility */
struct alloc_stat;
typedef int (*sort_fn_t)(void *, void *);
@@ -1673,7 +1677,8 @@ static int parse_sort_opt(const struct option *opt
__maybe_unused,
if (!arg)
return -1;
- if (kmem_page > kmem_slab) {
+ if (kmem_page > kmem_slab ||
+ (kmem_page == 0 && kmem_slab == 0 && kmem_default == KMEM_PAGE)) {
if (caller_flag > alloc_flag)
return setup_page_sorting(_caller_sort, arg);
else
@@ -1789,6 +1794,22 @@ static int __cmd_record(int argc, const char **argv)
return cmd_record(i, rec_argv, NULL);
}
+static int kmem_config(const char *var, const char *value, void *cb)
+{
+ if (!strcmp(var, "kmem.default")) {
+ if (!strcmp(value, "slab"))
+ kmem_default = KMEM_SLAB;
+ else if (!strcmp(value, "page"))
+ kmem_default = KMEM_PAGE;
+ else
+ pr_err("invalid default value ('slab' or 'page'
required): %s\n",
+ value);
+ return 0;
+ }
+
+ return perf_default_config(var, value, cb);
+}
+
int cmd_kmem(int argc, const char **argv, const char *prefix __maybe_unused)
{
const char * const default_slab_sort = "frag,hit,bytes";
@@ -1825,14 +1846,19 @@ int cmd_kmem(int argc, const char **argv, const char
*prefix __maybe_unused)
};
int ret = -1;
+ perf_config(kmem_config, NULL);
argc = parse_options_subcommand(argc, argv, kmem_options,
kmem_subcommands, kmem_usage, 0);
if (!argc)
usage_with_options(kmem_usage, kmem_options);
- if (kmem_slab == 0 && kmem_page == 0)
- kmem_slab = 1; /* for backward compatibility */
+ if (kmem_slab == 0 && kmem_page == 0) {
+ if (kmem_default == KMEM_SLAB)
+ kmem_slab = 1;
+ else
+ kmem_page = 1;
+ }
if (!strncmp(argv[0], "rec", 3)) {
symbol__init(NULL);
--
2.3.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 4/7] perf kmem: Support sort keys on page analysis
Add new sort keys for page: page, order, migtype, gfp - existing
'bytes', 'hit' and 'callsite' sort keys also work for page. Note that
-s/--sort option should be preceded by either of --slab or --page
option to determine where the sort keys applies.
Now it properly groups and sorts allocation stats - so same
page/caller with different order/migtype/gfp will be printed on a
different line.
# perf kmem stat --page --caller -l 10 -s order,hit
Total alloc (KB) | Hits | Order | Mig.type | GFP flags | Callsite
64 | 4 | 2 | RECLAIM | 00285250 | new_slab
50,144 |12,536 | 0 | MOVABLE | 0102005a |
__page_cache_alloc
52 |13 | 0 | UNMOVABL | 002084d0 | pte_alloc_one
40 |10 | 0 | MOVABLE | 000280da | handle_mm_fault
28 | 7 | 0 | UNMOVABL | 00d0 | __pollwait
20 | 5 | 0 | MOVABLE | 000200da | do_wp_page
20 | 5 | 0 | MOVABLE | 000200da | do_cow_fault
16 | 4 | 0 | UNMOVABL | 0200 |
__tlb_remove_page
16 | 4 | 0 | UNMOVABL | 84d0 | __pmd_alloc
8 | 2 | 0 | UNMOVABL | 84d0 | __pud_alloc
... | ... | ... | ... | ... | ...
Signed-off-by: Namhyung Kim
---
tools/perf/Documentation/perf-kmem.txt | 6 +-
tools/perf/builtin-kmem.c | 398 ++---
2 files changed, 317 insertions(+), 87 deletions(-)
diff --git a/tools/perf/Documentation/perf-kmem.txt
b/tools/perf/Documentation/perf-kmem.txt
index 23219c65c16f..69e181272c51 100644
--- a/tools/perf/Documentation/perf-kmem.txt
+++ b/tools/perf/Documentation/perf-kmem.txt
@@ -37,7 +37,11 @@ OPTIONS
-s ::
--sort=::
- Sort the output (default: frag,hit,bytes)
+ Sort the output (default: 'frag,hit,bytes' for slab and 'bytes,hit'
+ for page). Available sort keys are 'ptr, callsite, bytes, hit,
+ pingpong, frag' for slab and 'page, callsite, bytes, hit, order,
+ migtype, gfp' for page. This option should be preceded by one of the
+ mode selection options - i.e. --slab, --page, --alloc and/or --caller.
-l ::
--line=::
diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index 164218ff597f..a9ee73995eb5 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf/builtin-kmem.c
@@ -30,7 +30,7 @@ static intkmem_page;
static longkmem_page_size;
struct alloc_stat;
-typedef int (*sort_fn_t)(struct alloc_stat *, struct alloc_stat *);
+typedef int (*sort_fn_t)(void *, void *);
static int alloc_flag;
static int caller_flag;
@@ -181,8 +181,8 @@ static int perf_evsel__process_alloc_node_event(struct
perf_evsel *evsel,
return ret;
}
-static int ptr_cmp(struct alloc_stat *, struct alloc_stat *);
-static int callsite_cmp(struct alloc_stat *, struct alloc_stat *);
+static int ptr_cmp(void *, void *);
+static int slab_callsite_cmp(void *, void *);
static struct alloc_stat *search_alloc_stat(unsigned long ptr,
unsigned long call_site,
@@ -223,7 +223,8 @@ static int perf_evsel__process_free_event(struct perf_evsel
*evsel,
s_alloc->pingpong++;
s_caller = search_alloc_stat(0, s_alloc->call_site,
-_caller_stat, callsite_cmp);
+_caller_stat,
+slab_callsite_cmp);
if (!s_caller)
return -1;
s_caller->pingpong++;
@@ -397,6 +398,7 @@ static u64 find_callsite(struct perf_evsel *evsel, struct
perf_sample *sample)
return sample->ip;
}
+
static struct page_stat *search_page(u64 page, bool create)
{
struct rb_node **node = _tree.rb_node;
@@ -432,40 +434,35 @@ static struct page_stat *search_page(u64 page, bool
create)
return data;
}
-static int page_stat_cmp(struct page_stat *a, struct page_stat *b)
-{
- if (a->page > b->page)
- return -1;
- if (a->page < b->page)
- return 1;
- if (a->order > b->order)
- return -1;
- if (a->order < b->order)
- return 1;
- if (a->migrate_type > b->migrate_type)
- return -1;
- if (a->migrate_type < b->migrate_type)
- return 1;
- if (a->gfp_flags > b->gfp_flags)
- return -1;
- if (a->gfp_flags < b->gfp_flags)
- return 1;
- return
[PATCH 3/7] perf kmem: Implement stat --page --caller
It perf kmem support caller statistics for page. Unlike slab case,
the tracepoints in page allocator don't provide callsite info. So
it records with callchain and extracts callsite info.
Note that the callchain contains several memory allocation functions
which has no meaning for users. So skip those functions to get proper
callsites. I used following regex pattern to skip the allocator
functions:
^_?_?(alloc|get_free|get_zeroed)_pages?
This gave me a following list of functions:
# perf kmem record --page sleep 3
# perf kmem stat --page -v
...
alloc func: __get_free_pages
alloc func: get_zeroed_page
alloc func: alloc_pages_exact
alloc func: __alloc_pages_direct_compact
alloc func: __alloc_pages_nodemask
alloc func: alloc_page_interleave
alloc func: alloc_pages_current
alloc func: alloc_pages_vma
alloc func: alloc_page_buffers
alloc func: alloc_pages_exact_nid
...
The output looks mostly same as --alloc (I also added callsite column
to that) but groups entries by callsite. Currently, the order,
migrate type and GFP flag info is for the last allocation and not
guaranteed to be same for all allocations from the callsite.
-
Total_alloc (KB) | Hits | Order | Mig.type | GFP flags | Callsite
-
1,064 | 266 | 0 | UNMOVABL | 00d0 | __pollwait
52 |13 | 0 | UNMOVABL | 002084d0 | pte_alloc_one
44 |11 | 0 | MOVABLE | 000280da | handle_mm_fault
20 | 5 | 0 | MOVABLE | 000200da | do_cow_fault
20 | 5 | 0 | MOVABLE | 000200da | do_wp_page
16 | 4 | 0 | UNMOVABL | 84d0 | __pmd_alloc
16 | 4 | 0 | UNMOVABL | 0200 |
__tlb_remove_page
12 | 3 | 0 | UNMOVABL | 84d0 | __pud_alloc
8 | 2 | 0 | UNMOVABL | 0010 |
bio_copy_user_iov
4 | 1 | 0 | UNMOVABL | 000200d2 | pipe_write
4 | 1 | 0 | MOVABLE | 000280da | do_wp_page
4 | 1 | 0 | UNMOVABL | 002084d0 | pgd_alloc
-
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-kmem.c | 279 +++---
1 file changed, 263 insertions(+), 16 deletions(-)
diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index acd6764d03ef..164218ff597f 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf/builtin-kmem.c
@@ -10,6 +10,7 @@
#include "util/header.h"
#include "util/session.h"
#include "util/tool.h"
+#include "util/callchain.h"
#include "util/parse-options.h"
#include "util/trace-event.h"
@@ -21,6 +22,7 @@
#include
#include
#include
+#include
static int kmem_slab;
static int kmem_page;
@@ -241,6 +243,7 @@ static unsigned long nr_page_fails;
static unsigned long nr_page_nomatch;
static bool use_pfn;
+static struct perf_session *kmem_session;
#define MAX_MIGRATE_TYPES 6
#define MAX_PAGE_ORDER 11
@@ -250,6 +253,7 @@ static int order_stats[MAX_PAGE_ORDER][MAX_MIGRATE_TYPES];
struct page_stat {
struct rb_node node;
u64 page;
+ u64 callsite;
int order;
unsignedgfp_flags;
unsignedmigrate_type;
@@ -262,8 +266,138 @@ struct page_stat {
static struct rb_root page_tree;
static struct rb_root page_alloc_tree;
static struct rb_root page_alloc_sorted;
+static struct rb_root page_caller_tree;
+static struct rb_root page_caller_sorted;
-static struct page_stat *search_page(unsigned long page, bool create)
+struct alloc_func {
+ u64 start;
+ u64 end;
+ char *name;
+};
+
+static int nr_alloc_funcs;
+static struct alloc_func *alloc_func_list;
+
+static int funcmp(const void *a, const void *b)
+{
+ const struct alloc_func *fa = a;
+ const struct alloc_func *fb = b;
+
+ if (fa->start > fb->start)
+ return 1;
+ else
+ return -1;
+}
+
+static int callcmp(const void *a, const void *b)
+{
+ const struct alloc_func *fa = a;
+ const struct alloc_func *fb = b;
+
+ if (fb->start <= fa->start && fa->end < fb->end)
+ return 0;
+
+ if (fa->start > fb->start)
+ return 1;
+ else
+ return -1;
+}
+
+static int build_alloc_func_list(void)
+{
+ int ret;
+ struct map *kernel_map;
+ struct symbol *sym;
+ struct rb_node *node;
+ struct alloc_func *func;
+ struct machine *machine = _session->machines.host;
+
+ regex_t alloc_func_regex;
+ const char pattern[] =
Re: [PATCH] [RESEND][TRIVIAL] treewide: fix occurrences of "the the "
On 03/26/2015 06:55 PM, Michael Opdenacker wrote: > 222 files changed, 493 insertions(+), 258 deletions(-) Is this patch getting too big (and getting bigger and bigger) to be ever merged? Unless you tell me otherwise, I'm thinking about splitting it into several patches, one for each subsystem. That would unnecessarily increase the number of commits for the same thing, what else can we do? Michael. -- Michael Opdenacker, CEO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com +33 484 258 098 -- 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/7] perf kmem: Analyze page allocator events also
The perf kmem command records and analyze kernel memory allocation only for SLAB objects. This patch implement a simple page allocator analyzer using kmem:mm_page_alloc and kmem:mm_page_free events. It adds two new options of --slab and --page. The --slab option is for analyzing SLAB allocator and that's what perf kmem currently does. The new --page option enables page allocator events and analyze kernel memory usage in page unit. Currently, 'stat --alloc' subcommand is implemented only. If none of these --slab nor --page is specified, --slab is implied. # perf kmem stat --page --alloc --line 10 --- PFN | Total alloc (KB) | Hits | Order | Mig.type | GFP flags --- 4045014 | 16 |1 | 2 | RECLAIM | 00285250 4143980 | 16 |1 | 2 | RECLAIM | 00285250 3938658 | 16 |1 | 2 | RECLAIM | 00285250 4045400 | 16 |1 | 2 | RECLAIM | 00285250 3568708 | 16 |1 | 2 | RECLAIM | 00285250 3729824 | 16 |1 | 2 | RECLAIM | 00285250 3657210 | 16 |1 | 2 | RECLAIM | 00285250 4120750 | 16 |1 | 2 | RECLAIM | 00285250 3678850 | 16 |1 | 2 | RECLAIM | 00285250 3693874 | 16 |1 | 2 | RECLAIM | 00285250 ... | ... | ... | ... | ... | ... --- SUMMARY (page allocator) Total allocation requests : 44,260 [ 177,256 KB ] Total free requests : 117 [ 468 KB ] Total alloc+freed requests: 49 [ 196 KB ] Total alloc-only requests : 44,211 [ 177,060 KB ] Total free-only requests : 68 [ 272 KB ] Total allocation failures :0 [0 KB ] Order Unmovable Reclaimable Movable Reserved CMA/Isolated - 032 .44,210 . . 1 . . . . . 2 .18 . . . 3 . . . . . 4 . . . . . 5 . . . . . 6 . . . . . 7 . . . . . 8 . . . . . 9 . . . . . 10 . . . . . Signed-off-by: Namhyung Kim --- tools/perf/Documentation/perf-kmem.txt | 8 +- tools/perf/builtin-kmem.c | 500 +++-- 2 files changed, 491 insertions(+), 17 deletions(-) diff --git a/tools/perf/Documentation/perf-kmem.txt b/tools/perf/Documentation/perf-kmem.txt index 150253cc3c97..23219c65c16f 100644 --- a/tools/perf/Documentation/perf-kmem.txt +++ b/tools/perf/Documentation/perf-kmem.txt @@ -3,7 +3,7 @@ perf-kmem(1) NAME -perf-kmem - Tool to trace/measure kernel memory(slab) properties +perf-kmem - Tool to trace/measure kernel memory properties SYNOPSIS @@ -46,6 +46,12 @@ OPTIONS --raw-ip:: Print raw ip instead of symbol +--slab:: + Analyze SLAB allocator events. + +--page:: + Analyze page allocator events + SEE ALSO linkperf:perf-record[1] diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c index 64d3623d45a0..acd6764d03ef 100644 --- a/tools/perf/builtin-kmem.c +++ b/tools/perf/builtin-kmem.c @@ -22,6 +22,11 @@ #include #include +static int kmem_slab; +static int kmem_page; + +static longkmem_page_size; + struct alloc_stat; typedef int (*sort_fn_t)(struct alloc_stat *, struct alloc_stat *); @@ -226,6 +231,244 @@ static int perf_evsel__process_free_event(struct perf_evsel *evsel, return 0; } +static u64 total_page_alloc_bytes; +static u64 total_page_free_bytes; +static u64 total_page_nomatch_bytes; +static u64 total_page_fail_bytes; +static unsigned long nr_page_allocs; +static unsigned long nr_page_frees; +static unsigned long nr_page_fails; +static
[PATCH 1/7] tracing, mm: Record pfn instead of pointer to struct page
The struct page is opaque for userspace tools, so it'd be better to save
pfn in order to identify page frames.
The textual output of $debugfs/tracing/trace file remains unchanged and
only raw (binary) data format is changed - but thanks to libtraceevent,
userspace tools which deal with the raw data (like perf and trace-cmd)
can parse the format easily. So impact on the userspace will also be
minimal.
Based-on-patch-by: Joonsoo Kim
Acked-by: Ingo Molnar
Cc: Steven Rostedt
Cc: linux...@kvack.org
Signed-off-by: Namhyung Kim
---
include/trace/events/filemap.h | 8
include/trace/events/kmem.h| 42 +-
include/trace/events/vmscan.h | 8
3 files changed, 29 insertions(+), 29 deletions(-)
diff --git a/include/trace/events/filemap.h b/include/trace/events/filemap.h
index 0421f49a20f7..42febb6bc1d5 100644
--- a/include/trace/events/filemap.h
+++ b/include/trace/events/filemap.h
@@ -18,14 +18,14 @@ DECLARE_EVENT_CLASS(mm_filemap_op_page_cache,
TP_ARGS(page),
TP_STRUCT__entry(
- __field(struct page *, page)
+ __field(unsigned long, pfn)
__field(unsigned long, i_ino)
__field(unsigned long, index)
__field(dev_t, s_dev)
),
TP_fast_assign(
- __entry->page = page;
+ __entry->pfn = page_to_pfn(page);
__entry->i_ino = page->mapping->host->i_ino;
__entry->index = page->index;
if (page->mapping->host->i_sb)
@@ -37,8 +37,8 @@ DECLARE_EVENT_CLASS(mm_filemap_op_page_cache,
TP_printk("dev %d:%d ino %lx page=%p pfn=%lu ofs=%lu",
MAJOR(__entry->s_dev), MINOR(__entry->s_dev),
__entry->i_ino,
- __entry->page,
- page_to_pfn(__entry->page),
+ pfn_to_page(__entry->pfn),
+ __entry->pfn,
__entry->index << PAGE_SHIFT)
);
diff --git a/include/trace/events/kmem.h b/include/trace/events/kmem.h
index 4ad10baecd4d..81ea59812117 100644
--- a/include/trace/events/kmem.h
+++ b/include/trace/events/kmem.h
@@ -154,18 +154,18 @@ TRACE_EVENT(mm_page_free,
TP_ARGS(page, order),
TP_STRUCT__entry(
- __field(struct page *, page)
+ __field(unsigned long, pfn )
__field(unsigned int, order )
),
TP_fast_assign(
- __entry->page = page;
+ __entry->pfn= page_to_pfn(page);
__entry->order = order;
),
TP_printk("page=%p pfn=%lu order=%d",
- __entry->page,
- page_to_pfn(__entry->page),
+ pfn_to_page(__entry->pfn),
+ __entry->pfn,
__entry->order)
);
@@ -176,18 +176,18 @@ TRACE_EVENT(mm_page_free_batched,
TP_ARGS(page, cold),
TP_STRUCT__entry(
- __field(struct page *, page)
+ __field(unsigned long, pfn )
__field(int,cold)
),
TP_fast_assign(
- __entry->page = page;
+ __entry->pfn= page_to_pfn(page);
__entry->cold = cold;
),
TP_printk("page=%p pfn=%lu order=0 cold=%d",
- __entry->page,
- page_to_pfn(__entry->page),
+ pfn_to_page(__entry->pfn),
+ __entry->pfn,
__entry->cold)
);
@@ -199,22 +199,22 @@ TRACE_EVENT(mm_page_alloc,
TP_ARGS(page, order, gfp_flags, migratetype),
TP_STRUCT__entry(
- __field(struct page *, page)
+ __field(unsigned long, pfn )
__field(unsigned int, order )
__field(gfp_t, gfp_flags )
__field(int,migratetype )
),
TP_fast_assign(
- __entry->page = page;
+ __entry->pfn= page ? page_to_pfn(page) : -1UL;
__entry->order = order;
__entry->gfp_flags = gfp_flags;
__entry->migratetype= migratetype;
),
TP_printk("page=%p pfn=%lu order=%d migratetype=%d gfp_flags=%s",
- __entry->page,
- __entry->page ? page_to_pfn(__entry->page) : 0,
+ __entry->pfn != -1UL ? pfn_to_page(__entry->pfn) : NULL,
+ __entry->pfn != -1UL ? __entry->pfn : 0,
__entry->order,
__entry->migratetype,
show_gfp_flags(__entry->gfp_flags))
@@ -227,20 +227,20 @@
[PATCH 5/7] perf kmem: Add --live option for current allocation stat
Currently perf kmem shows total (page) allocation stat by default, but
sometimes one might want to see live (total alloc-only) requests/pages
only. The new --live option does this by subtracting freed allocation
from the stat.
Signed-off-by: Namhyung Kim
---
tools/perf/Documentation/perf-kmem.txt | 5 ++
tools/perf/builtin-kmem.c | 103 -
2 files changed, 69 insertions(+), 39 deletions(-)
diff --git a/tools/perf/Documentation/perf-kmem.txt
b/tools/perf/Documentation/perf-kmem.txt
index 69e181272c51..ff0f433b3fce 100644
--- a/tools/perf/Documentation/perf-kmem.txt
+++ b/tools/perf/Documentation/perf-kmem.txt
@@ -56,6 +56,11 @@ OPTIONS
--page::
Analyze page allocator events
+--live::
+ Show live page stat. The perf kmem shows total allocation stat by
+ default, but this option shows live (currently allocated) pages
+ instead. (This option works with --page option only)
+
SEE ALSO
linkperf:perf-record[1]
diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index a9ee73995eb5..863d882d6a94 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf/builtin-kmem.c
@@ -244,6 +244,7 @@ static unsigned long nr_page_fails;
static unsigned long nr_page_nomatch;
static bool use_pfn;
+static bool live_page;
static struct perf_session *kmem_session;
#define MAX_MIGRATE_TYPES 6
@@ -264,7 +265,7 @@ struct page_stat {
int nr_free;
};
-static struct rb_root page_tree;
+static struct rb_root page_live_tree;
static struct rb_root page_alloc_tree;
static struct rb_root page_alloc_sorted;
static struct rb_root page_caller_tree;
@@ -398,10 +399,19 @@ static u64 find_callsite(struct perf_evsel *evsel, struct
perf_sample *sample)
return sample->ip;
}
+struct sort_dimension {
+ const char name[20];
+ sort_fn_t cmp;
+ struct list_headlist;
+};
+
+static LIST_HEAD(page_alloc_sort_input);
+static LIST_HEAD(page_caller_sort_input);
-static struct page_stat *search_page(u64 page, bool create)
+static struct page_stat *search_page_live_stat(struct page_stat *this,
+ bool create)
{
- struct rb_node **node = _tree.rb_node;
+ struct rb_node **node = _live_tree.rb_node;
struct rb_node *parent = NULL;
struct page_stat *data;
@@ -411,7 +421,7 @@ static struct page_stat *search_page(u64 page, bool create)
parent = *node;
data = rb_entry(*node, struct page_stat, node);
- cmp = data->page - page;
+ cmp = data->page - this->page;
if (cmp < 0)
node = >rb_left;
else if (cmp > 0)
@@ -425,24 +435,17 @@ static struct page_stat *search_page(u64 page, bool
create)
data = zalloc(sizeof(*data));
if (data != NULL) {
- data->page = page;
+ data->page = this->page;
+ data->order = this->order;
+ data->migrate_type = this->migrate_type;
+ data->gfp_flags = this->gfp_flags;
rb_link_node(>node, parent, node);
- rb_insert_color(>node, _tree);
+ rb_insert_color(>node, _live_tree);
}
return data;
}
-
-struct sort_dimension {
- const char name[20];
- sort_fn_t cmp;
- struct list_headlist;
-};
-
-static LIST_HEAD(page_alloc_sort_input);
-static LIST_HEAD(page_caller_sort_input);
-
static struct page_stat *search_page_alloc_stat(struct page_stat *this,
bool create)
{
@@ -580,17 +583,8 @@ static int perf_evsel__process_page_alloc_event(struct
perf_evsel *evsel,
* This is to find the current page (with correct gfp flags and
* migrate type) at free event.
*/
- stat = search_page(page, true);
- if (stat == NULL)
- return -ENOMEM;
-
- stat->order = order;
- stat->gfp_flags = gfp_flags;
- stat->migrate_type = migrate_type;
- stat->callsite = callsite;
-
this.page = page;
- stat = search_page_alloc_stat(, true);
+ stat = search_page_live_stat(, true);
if (stat == NULL)
return -ENOMEM;
@@ -598,6 +592,16 @@ static int perf_evsel__process_page_alloc_event(struct
perf_evsel *evsel,
stat->alloc_bytes += bytes;
stat->callsite = callsite;
+ if (!live_page) {
+ stat = search_page_alloc_stat(, true);
+ if (stat == NULL)
+ return -ENOMEM;
+
+ stat->nr_alloc++;
+ stat->alloc_bytes += bytes;
+ stat->callsite = callsite;
+ }
+
this.callsite = callsite;
stat = search_page_caller_stat(, true);
if (stat == NULL)
@@ -630,7 +634,8 @@ static int
[PATCHSET 0/7] perf kmem: Implement page allocation analysis (v5)
Hello, Currently perf kmem command only analyzes SLAB memory allocation. And I'd like to introduce page allocation analysis also. Users can use --slab and/or --page option to select it. If none of these options are used, it does slab allocation analysis for backward compatibility. * changes in v5) - print migration type and gfp flags in more compact form (Arnaldo) - add kmem.default config option * changes in v4) - use pfn instead of struct page * in tracepoints (Joonsoo, Ingo) - print gfp flags in human readable string (Joonsoo, Minchan) * changes in v3) - add live page statistics * changes in v2) - Use thousand grouping for big numbers - i.e. 12345 -> 12,345 (Ingo) - Improve output stat readability (Ingo) - Remove alloc size column as it can be calculated from hits and order Patch 1 is to convert tracepoint to save pfn instead of struct page *. Patch 2 implements basic support for page allocation analysis, patch 3 deals with the callsite and patch 4 implements sorting. Patch 5 introduces live page analysis which is to focus on currently allocated pages only. Patch 6 prints gfp flags in human readable string and patch 7 adds kmem.default config option to be able to select page analysis by default. In this patchset, I used two kmem events: kmem:mm_page_alloc and kmem_page_free for analysis as they can track almost all of memory allocation/free path AFAIK. However, unlike slab tracepoint events, those page allocation events don't provide callsite info directly. So I recorded callchains and extracted callsites like below: Normal page allocation callchains look like this: 360a7e __alloc_pages_nodemask 3a711c alloc_pages_current 357bc7 __page_cache_alloc <-- callsite 357cf6 pagecache_get_page 48b0a prepare_pages 494d3 __btrfs_buffered_write 49cdf btrfs_file_write_iter 3ceb6e new_sync_write 3cf447 vfs_write 3cff99 sys_write 7556e9 system_call f880 __write_nocancel 33eb9 cmd_record 4b38e cmd_kmem 7aa23 run_builtin 27a9a main 20800 __libc_start_main But first two are internal page allocation functions so it should be skipped. To determine such allocation functions, I used following regex: ^_?_?(alloc|get_free|get_zeroed)_pages? This gave me a following list of functions (you can see this with -v): alloc func: __get_free_pages alloc func: get_zeroed_page alloc func: alloc_pages_exact alloc func: __alloc_pages_direct_compact alloc func: __alloc_pages_nodemask alloc func: alloc_page_interleave alloc func: alloc_pages_current alloc func: alloc_pages_vma alloc func: alloc_page_buffers alloc func: alloc_pages_exact_nid After skipping those function, it got '__page_cache_alloc'. Other information such as allocation order, migration type and gfp flags are provided by tracepoint events. Basically the output will be sorted by total allocation bytes, but you can change it by using -s/--sort option. The following sort keys are added to support page analysis: page, order, mtype, gfp. Existing 'callsite', 'bytes' and 'hit' sort keys also can be used. An example follows: # perf kmem record --page sleep 5 [ perf record: Woken up 2 times to write data ] [ perf record: Captured and wrote 1.065 MB perf.data (2949 samples) ] # perf kmem stat --page # GFP flags # - # 0010: NI: GFP_NOIO # 00d0: K: GFP_KERNEL # 0200:NWR: GFP_NOWARN # 52d0: K|NWR|NR|C: GFP_KERNEL|GFP_NOWARN|GFP_NORETRY|GFP_COMP # 84d0: K|R|Z: GFP_KERNEL|GFP_REPEAT|GFP_ZERO # 000200d0: U: GFP_USER # 000200d2: HU: GFP_HIGHUSER # 000200da:HUM: GFP_HIGHUSER_MOVABLE # 000280da: HUM|Z: GFP_HIGHUSER_MOVABLE|GFP_ZERO # 002084d0: K|R|Z|NT: GFP_KERNEL|GFP_REPEAT|GFP_ZERO|GFP_NOTRACK # 0102005a:NF|HW|M: GFP_NOFS|GFP_HARDWALL|GFP_MOVABLE - Total alloc (KB) | Hits | Order | Mig.type | GFP flags | Callsite - 3,876 | 969 | 0 | MOVABLE | HUM| shmem_alloc_page 972 | 243 | 0 | UNMOVABL | K | __pollwait 624 | 156 | 0 | MOVABLE | NF|HW|M| __page_cache_alloc 304 |76 | 0 | UNMOVABL | U | dma_generic_alloc_coherent 108 |27 | 0 | MOVABLE | HUM|Z | handle_mm_fault 56 |14 | 0 | UNMOVABL | K|R|Z|NT | pte_alloc_one 24 | 6 | 0 | MOVABLE | HUM| do_wp_page 24 | 3 | 1 | UNMOVABL | K|NWR|NR|C | alloc_skb_with_frags 16 | 4 | 0 | UNMOVABL | NWR| __tlb_remove_page 16 | 4 | 0 | MOVABLE | HUM|
god morgen
god morgen Dette er en melding om at Uni_Credit lån tilbyr lån til de trengende i en lav rente på 3% og uten kredittsjekk, vi tilbyr personlige lån, gjeld konsolidering De lån, venture kapital, business lån, utdanning lån eller lån eller annen grunn. Hvis interessert, ta kontakt med oss. Ta kontakt med følgende informasjon navn: land: Beløpet som trengs: varighet: sex: alder: telefon: Du kan også kontakte oss: uni_credit_l...@outlook.com Takk Ms Ana Giorgia --- This email has been checked for viruses by Avast antivirus software. http://www.avast.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/
[PATCH v2 01/16] net: dsa: mv88e6xxx: Factor out common initialization code
Code used and needed in mv886xxx.c should be initialized there as well,
so factor it out from the individual initialization files.
Reviewed-by: Andrew Lunn
Tested-by: Andrew Lunn
Signed-off-by: Guenter Roeck
---
drivers/net/dsa/mv88e6123_61_65.c | 7 +++
drivers/net/dsa/mv88e6171.c | 8 +++-
drivers/net/dsa/mv88e6352.c | 7 ---
drivers/net/dsa/mv88e6xxx.c | 11 +++
drivers/net/dsa/mv88e6xxx.h | 1 +
5 files changed, 22 insertions(+), 12 deletions(-)
diff --git a/drivers/net/dsa/mv88e6123_61_65.c
b/drivers/net/dsa/mv88e6123_61_65.c
index e9c736e1cef3..6ebe57044afc 100644
--- a/drivers/net/dsa/mv88e6123_61_65.c
+++ b/drivers/net/dsa/mv88e6123_61_65.c
@@ -293,13 +293,12 @@ static int mv88e6123_61_65_setup_port(struct dsa_switch
*ds, int p)
static int mv88e6123_61_65_setup(struct dsa_switch *ds)
{
- struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
int i;
int ret;
- mutex_init(>smi_mutex);
- mutex_init(>stats_mutex);
- mutex_init(>phy_mutex);
+ ret = mv88e6xxx_setup_common(ds);
+ if (ret < 0)
+ return ret;
ret = mv88e6123_61_65_switch_reset(ds);
if (ret < 0)
diff --git a/drivers/net/dsa/mv88e6171.c b/drivers/net/dsa/mv88e6171.c
index 9808c860a797..2f6662c246fa 100644
--- a/drivers/net/dsa/mv88e6171.c
+++ b/drivers/net/dsa/mv88e6171.c
@@ -292,12 +292,12 @@ static int mv88e6171_setup_port(struct dsa_switch *ds,
int p)
static int mv88e6171_setup(struct dsa_switch *ds)
{
- struct mv88e6xxx_priv_state *ps = (void *)(ds + 1);
int i;
int ret;
- mutex_init(>smi_mutex);
- mutex_init(>stats_mutex);
+ ret = mv88e6xxx_setup_common(ds);
+ if (ret < 0)
+ return ret;
ret = mv88e6171_switch_reset(ds);
if (ret < 0)
@@ -318,8 +318,6 @@ static int mv88e6171_setup(struct dsa_switch *ds)
return ret;
}
- mutex_init(>phy_mutex);
-
return 0;
}
diff --git a/drivers/net/dsa/mv88e6352.c b/drivers/net/dsa/mv88e6352.c
index 7bc5998384c6..75cf9e1c5a44 100644
--- a/drivers/net/dsa/mv88e6352.c
+++ b/drivers/net/dsa/mv88e6352.c
@@ -385,9 +385,10 @@ static int mv88e6352_setup(struct dsa_switch *ds)
int ret;
int i;
- mutex_init(>smi_mutex);
- mutex_init(>stats_mutex);
- mutex_init(>phy_mutex);
+ ret = mv88e6xxx_setup_common(ds);
+ if (ret < 0)
+ return ret;
+
mutex_init(>eeprom_mutex);
ps->id = REG_READ(REG_PORT(0), 0x03) & 0xfff0;
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index c18ffc98aacc..6496beb74510 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -700,6 +700,17 @@ int mv88e6xxx_set_eee(struct dsa_switch *ds, int port,
return 0;
}
+int mv88e6xxx_setup_common(struct dsa_switch *ds)
+{
+ struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
+
+ mutex_init(>smi_mutex);
+ mutex_init(>stats_mutex);
+ mutex_init(>phy_mutex);
+
+ return 0;
+}
+
static int __init mv88e6xxx_init(void)
{
#if IS_ENABLED(CONFIG_NET_DSA_MV88E6131)
diff --git a/drivers/net/dsa/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx.h
index 5fd42ced9011..a02d95a9b313 100644
--- a/drivers/net/dsa/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx.h
@@ -57,6 +57,7 @@ struct mv88e6xxx_hw_stat {
int reg;
};
+int mv88e6xxx_setup_common(struct dsa_switch *ds);
int __mv88e6xxx_reg_read(struct mii_bus *bus, int sw_addr, int addr, int reg);
int mv88e6xxx_reg_read(struct dsa_switch *ds, int addr, int reg);
int __mv88e6xxx_reg_write(struct mii_bus *bus, int sw_addr, int addr,
--
2.1.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 v2 02/16] net: dsa: mv88e6xxx: Provide function for common port initialization
Provide mv88e6xxx_setup_port_common() for common port initialization.
Currently only write Port 1 Control and VLAN configuration since
this will be needed for hardware bridging. More can be added later
if desired/needed.
Reviewed-by: Andrew Lunn
Tested-by: Andrew Lunn
Signed-off-by: Guenter Roeck
---
drivers/net/dsa/mv88e6xxx.c | 39 +++
drivers/net/dsa/mv88e6xxx.h | 1 +
2 files changed, 40 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 6496beb74510..2052e51edd5d 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -700,6 +700,45 @@ int mv88e6xxx_set_eee(struct dsa_switch *ds, int port,
return 0;
}
+int mv88e6xxx_setup_port_common(struct dsa_switch *ds, int port)
+{
+ struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
+ int ret, reg;
+
+ mutex_lock(>smi_mutex);
+
+ /* Port Control 1: disable trunking. Also, if this is the
+* CPU port, enable learn messages to be sent to this port.
+*/
+ ret = _mv88e6xxx_reg_write(ds, REG_PORT(port), 0x05,
+ dsa_is_cpu_port(ds, port) ? 0x8000 : 0x);
+ if (ret)
+ goto abort;
+
+ /* Port based VLAN map: give each port its own address
+* database, allow the CPU port to talk to each of the 'real'
+* ports, and allow each of the 'real' ports to only talk to
+* the upstream port.
+*/
+ reg = (port & 0xf) << 12;
+ if (dsa_is_cpu_port(ds, port))
+ reg |= ds->phys_port_mask;
+ else
+ reg |= 1 << dsa_upstream_port(ds);
+
+ ret = _mv88e6xxx_reg_write(ds, REG_PORT(port), 0x06, reg);
+ if (ret)
+ goto abort;
+
+ /* Default VLAN ID and priority: don't set a default VLAN
+* ID, and set the default packet priority to zero.
+*/
+ ret = _mv88e6xxx_reg_write(ds, REG_PORT(port), 0x07, 0x);
+abort:
+ mutex_unlock(>smi_mutex);
+ return ret;
+}
+
int mv88e6xxx_setup_common(struct dsa_switch *ds)
{
struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
diff --git a/drivers/net/dsa/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx.h
index a02d95a9b313..a4df4968594e 100644
--- a/drivers/net/dsa/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx.h
@@ -57,6 +57,7 @@ struct mv88e6xxx_hw_stat {
int reg;
};
+int mv88e6xxx_setup_port_common(struct dsa_switch *ds, int port);
int mv88e6xxx_setup_common(struct dsa_switch *ds);
int __mv88e6xxx_reg_read(struct mii_bus *bus, int sw_addr, int addr, int reg);
int mv88e6xxx_reg_read(struct dsa_switch *ds, int addr, int reg);
--
2.1.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 v2 04/16] net: dsa: mv88e6xxx: Split mv88e6xxx_reg_read and mv88e6xxx_reg_write
Split mv88e6xxx_reg_read and mv88e6xxx_reg_write into two functions each,
one to acquire smi_mutex and one to get struct mii_bus *bus from
struct dsa_switch *ds and to call the actual read/write function.
Reviewed-by: Andrew Lunn
Tested-by: Andrew Lunn
Signed-off-by: Guenter Roeck
---
drivers/net/dsa/mv88e6xxx.c | 35 ++-
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 5da50b00fdf6..d8f13327a438 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -72,19 +72,16 @@ int __mv88e6xxx_reg_read(struct mii_bus *bus, int sw_addr,
int addr, int reg)
return ret & 0x;
}
-int mv88e6xxx_reg_read(struct dsa_switch *ds, int addr, int reg)
+/* Must be called with SMI mutex held */
+static int _mv88e6xxx_reg_read(struct dsa_switch *ds, int addr, int reg)
{
- struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
struct mii_bus *bus = dsa_host_dev_to_mii_bus(ds->master_dev);
int ret;
if (bus == NULL)
return -EINVAL;
- mutex_lock(>smi_mutex);
ret = __mv88e6xxx_reg_read(bus, ds->pd->sw_addr, addr, reg);
- mutex_unlock(>smi_mutex);
-
if (ret < 0)
return ret;
@@ -94,6 +91,18 @@ int mv88e6xxx_reg_read(struct dsa_switch *ds, int addr, int
reg)
return ret;
}
+int mv88e6xxx_reg_read(struct dsa_switch *ds, int addr, int reg)
+{
+ struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
+ int ret;
+
+ mutex_lock(>smi_mutex);
+ ret = _mv88e6xxx_reg_read(ds, addr, reg);
+ mutex_unlock(>smi_mutex);
+
+ return ret;
+}
+
int __mv88e6xxx_reg_write(struct mii_bus *bus, int sw_addr, int addr,
int reg, u16 val)
{
@@ -125,11 +134,11 @@ int __mv88e6xxx_reg_write(struct mii_bus *bus, int
sw_addr, int addr,
return 0;
}
-int mv88e6xxx_reg_write(struct dsa_switch *ds, int addr, int reg, u16 val)
+/* Must be called with SMI mutex held */
+static int _mv88e6xxx_reg_write(struct dsa_switch *ds, int addr, int reg,
+ u16 val)
{
- struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
struct mii_bus *bus = dsa_host_dev_to_mii_bus(ds->master_dev);
- int ret;
if (bus == NULL)
return -EINVAL;
@@ -137,8 +146,16 @@ int mv88e6xxx_reg_write(struct dsa_switch *ds, int addr,
int reg, u16 val)
dev_dbg(ds->master_dev, "-> addr: 0x%.2x reg: 0x%.2x val: 0x%.4x\n",
addr, reg, val);
+ return __mv88e6xxx_reg_write(bus, ds->pd->sw_addr, addr, reg, val);
+}
+
+int mv88e6xxx_reg_write(struct dsa_switch *ds, int addr, int reg, u16 val)
+{
+ struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
+ int ret;
+
mutex_lock(>smi_mutex);
- ret = __mv88e6xxx_reg_write(bus, ds->pd->sw_addr, addr, reg, val);
+ ret = _mv88e6xxx_reg_write(ds, addr, reg, val);
mutex_unlock(>smi_mutex);
return ret;
--
2.1.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 v2 00/16] net: dsa: HW bridging, EEE support
Patch 1 to 7 of this series prepare the drivers using the mv88e6xxx code for HW bridging support, without adding the code itself. For the most part this factors out common port initialization code. There is no functional change except for patch 3, which disables the message port bit for the CPU port to prevent packet duplication if HW bridging is configured. Patch 8 adds the infrastructure for hardware bridging support to the mv88e6xxx code. Patch 9 wires the MV88E6352 driver to support hardware bridging. Patches 10 to 12 add support for ndo_fdb functions to the dsa subsystem, and wire up the MV88E6352 driver to support those functions. Patches 13 to 16 add EEE support and HW bridging support to the mv88e6171 driver. This set of patches is from Andrew, applied on top of the first set of patches. The series applies to net-next as of 3/24/2015. Thanks a lot to Andrew Lunn for testing and valuable feedback. --- Changes since v1: - Fixed compile error in patch 02/16. That was previously addressed in a later patch but broke bisectability. - Dropped the RFT patches introducing HW bridging support for MV88E6131 and compatibles. There was a bug in stat code, and those patches should be handled separately anyway since they are untested. - Removed duplicate defines from mv88e6xxx.h. Changes since RFT: - Various bug fixes - Fixed packet duplication seen when HW bridging is enabled - Cleanup; use more defines and restructure patches - Added ndo_fdb functions - New patches adding support for HW bridging and EEE support to the mv88e6171 driver. -- 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 08/16] net: dsa: mv88e6xxx: Add Hardware bridging support
Bridge support is similar for all chips supported by the mv88e6xxx code,
so add the code there.
Reviewed-by: Andrew Lunn
Tested-by: Andrew Lunn
Signed-off-by: Guenter Roeck
---
drivers/net/dsa/mv88e6xxx.c | 271 ++--
drivers/net/dsa/mv88e6xxx.h | 28 +
2 files changed, 292 insertions(+), 7 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index d8f13327a438..17aa74f64233 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -9,6 +9,7 @@
*/
#include
+#include
#include
#include
#include
@@ -644,6 +645,31 @@ int mv88e6xxx_eeprom_busy_wait(struct dsa_switch *ds)
return mv88e6xxx_wait(ds, REG_GLOBAL2, 0x14, 0x8000);
}
+/* Must be called with SMI lock held */
+static int _mv88e6xxx_wait(struct dsa_switch *ds, int reg, int offset, u16
mask)
+{
+ unsigned long timeout = jiffies + HZ / 10;
+
+ while (time_before(jiffies, timeout)) {
+ int ret;
+
+ ret = _mv88e6xxx_reg_read(ds, reg, offset);
+ if (ret < 0)
+ return ret;
+ if (!(ret & mask))
+ return 0;
+
+ usleep_range(1000, 2000);
+ }
+ return -ETIMEDOUT;
+}
+
+/* Must be called with SMI lock held */
+static int _mv88e6xxx_atu_wait(struct dsa_switch *ds)
+{
+ return _mv88e6xxx_wait(ds, REG_GLOBAL, 0x0b, ATU_BUSY);
+}
+
int mv88e6xxx_phy_read_indirect(struct dsa_switch *ds, int addr, int regnum)
{
int ret;
@@ -717,10 +743,236 @@ int mv88e6xxx_set_eee(struct dsa_switch *ds, int port,
return 0;
}
+static int _mv88e6xxx_atu_cmd(struct dsa_switch *ds, int fid, u16 cmd)
+{
+ int ret;
+
+ ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, 0x01, fid);
+ if (ret < 0)
+ return ret;
+
+ ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, 0x0b, cmd);
+ if (ret < 0)
+ return ret;
+
+ return _mv88e6xxx_atu_wait(ds);
+}
+
+static int _mv88e6xxx_flush_fid(struct dsa_switch *ds, int fid)
+{
+ int ret;
+
+ ret = _mv88e6xxx_atu_wait(ds);
+ if (ret < 0)
+ return ret;
+
+ return _mv88e6xxx_atu_cmd(ds, fid, ATU_CMD_FLUSH_NONSTATIC_FID);
+}
+
+static int mv88e6xxx_set_port_state(struct dsa_switch *ds, int port, u8 state)
+{
+ struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
+ int reg, ret;
+ u8 oldstate;
+
+ mutex_lock(>smi_mutex);
+
+ reg = _mv88e6xxx_reg_read(ds, REG_PORT(port), 0x04);
+ if (reg < 0)
+ goto abort;
+
+ oldstate = reg & PSTATE_MASK;
+ if (oldstate != state) {
+ /* Flush forwarding database if we're moving a port
+* from Learning or Forwarding state to Disabled or
+* Blocking or Listening state.
+*/
+ if (oldstate >= PSTATE_LEARNING && state <= PSTATE_BLOCKING) {
+ ret = _mv88e6xxx_flush_fid(ds, ps->fid[port]);
+ if (ret)
+ goto abort;
+ }
+ reg = (reg & ~PSTATE_MASK) | state;
+ ret = _mv88e6xxx_reg_write(ds, REG_PORT(port), 0x04, reg);
+ }
+
+abort:
+ mutex_unlock(>smi_mutex);
+ return ret;
+}
+
+/* Must be called with smi lock held */
+static int _mv88e6xxx_update_port_config(struct dsa_switch *ds, int port)
+{
+ struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
+ u8 fid = ps->fid[port];
+ u16 reg = fid << 12;
+
+ if (dsa_is_cpu_port(ds, port))
+ reg |= ds->phys_port_mask;
+ else
+ reg |= (ps->bridge_mask[fid] |
+ (1 << dsa_upstream_port(ds))) & ~(1 << port);
+
+ return _mv88e6xxx_reg_write(ds, REG_PORT(port), 0x06, reg);
+}
+
+/* Must be called with smi lock held */
+static int _mv88e6xxx_update_bridge_config(struct dsa_switch *ds, int fid)
+{
+ struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
+ int port;
+ u32 mask;
+ int ret;
+
+ mask = ds->phys_port_mask;
+ while (mask) {
+ port = __ffs(mask);
+ mask &= ~(1 << port);
+ if (ps->fid[port] != fid)
+ continue;
+
+ ret = _mv88e6xxx_update_port_config(ds, port);
+ if (ret)
+ return ret;
+ }
+
+ return _mv88e6xxx_flush_fid(ds, fid);
+}
+
+/* Bridge handling functions */
+
+int mv88e6xxx_join_bridge(struct dsa_switch *ds, int port, u32 br_port_mask)
+{
+ struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
+ int ret = 0;
+ u32 nmask;
+ int fid;
+
+ /* If the bridge group is not empty, join that group.
+* Otherwise create a new group.
+*/
+ fid = ps->fid[port];
+ nmask = br_port_mask & ~(1 << port);
+ if (nmask)
+ fid = ps->fid[__ffs(nmask)];
+
+ nmask =
[PATCH v2 06/16] net: dsa: mv88e6123_61_65: Use common port configuration
This will simplify adding offloaded bridge support later on. Reviewed-by: Andrew Lunn Signed-off-by: Guenter Roeck --- drivers/net/dsa/mv88e6123_61_65.c | 24 +--- 1 file changed, 1 insertion(+), 23 deletions(-) diff --git a/drivers/net/dsa/mv88e6123_61_65.c b/drivers/net/dsa/mv88e6123_61_65.c index 6ebe57044afc..2d7e1ffe9fdc 100644 --- a/drivers/net/dsa/mv88e6123_61_65.c +++ b/drivers/net/dsa/mv88e6123_61_65.c @@ -222,28 +222,6 @@ static int mv88e6123_61_65_setup_port(struct dsa_switch *ds, int p) val |= 0x000c; REG_WRITE(addr, 0x04, val); - /* Port Control 1: disable trunking. Also, if this is the -* CPU port, enable learn messages to be sent to this port. -*/ - REG_WRITE(addr, 0x05, dsa_is_cpu_port(ds, p) ? 0x8000 : 0x); - - /* Port based VLAN map: give each port its own address -* database, allow the CPU port to talk to each of the 'real' -* ports, and allow each of the 'real' ports to only talk to -* the upstream port. -*/ - val = (p & 0xf) << 12; - if (dsa_is_cpu_port(ds, p)) - val |= ds->phys_port_mask; - else - val |= 1 << dsa_upstream_port(ds); - REG_WRITE(addr, 0x06, val); - - /* Default VLAN ID and priority: don't set a default VLAN -* ID, and set the default packet priority to zero. -*/ - REG_WRITE(addr, 0x07, 0x); - /* Port Control 2: don't force a good FCS, set the maximum * frame size to 10240 bytes, don't let the switch add or * strip 802.1q tags, don't discard tagged or untagged frames @@ -288,7 +266,7 @@ static int mv88e6123_61_65_setup_port(struct dsa_switch *ds, int p) */ REG_WRITE(addr, 0x19, 0x7654); - return 0; + return mv88e6xxx_setup_port_common(ds, p); } static int mv88e6123_61_65_setup(struct dsa_switch *ds) -- 2.1.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 v2 07/16] net: dsa: mv88e6171: Use common port configuration
Reviewed-by: Andrew Lunn Tested-by: Andrew Lunn Signed-off-by: Guenter Roeck --- drivers/net/dsa/mv88e6171.c | 24 +--- 1 file changed, 1 insertion(+), 23 deletions(-) diff --git a/drivers/net/dsa/mv88e6171.c b/drivers/net/dsa/mv88e6171.c index 2f6662c246fa..6ce6a3ea1b8d 100644 --- a/drivers/net/dsa/mv88e6171.c +++ b/drivers/net/dsa/mv88e6171.c @@ -221,28 +221,6 @@ static int mv88e6171_setup_port(struct dsa_switch *ds, int p) val |= 0x000c; REG_WRITE(addr, 0x04, val); - /* Port Control 1: disable trunking. Also, if this is the -* CPU port, enable learn messages to be sent to this port. -*/ - REG_WRITE(addr, 0x05, dsa_is_cpu_port(ds, p) ? 0x8000 : 0x); - - /* Port based VLAN map: give each port its own address -* database, allow the CPU port to talk to each of the 'real' -* ports, and allow each of the 'real' ports to only talk to -* the upstream port. -*/ - val = (p & 0xf) << 12; - if (dsa_is_cpu_port(ds, p)) - val |= ds->phys_port_mask; - else - val |= 1 << dsa_upstream_port(ds); - REG_WRITE(addr, 0x06, val); - - /* Default VLAN ID and priority: don't set a default VLAN -* ID, and set the default packet priority to zero. -*/ - REG_WRITE(addr, 0x07, 0x); - /* Port Control 2: don't force a good FCS, set the maximum * frame size to 10240 bytes, don't let the switch add or * strip 802.1q tags, don't discard tagged or untagged frames @@ -287,7 +265,7 @@ static int mv88e6171_setup_port(struct dsa_switch *ds, int p) */ REG_WRITE(addr, 0x19, 0x7654); - return 0; + return mv88e6xxx_setup_port_common(ds, p); } static int mv88e6171_setup(struct dsa_switch *ds) -- 2.1.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] mtd: hisilicon: remove deprecated IRQF_DISABLED
This removes the use of the IRQF_DISABLED flag
from drivers/mtd/nand/hisi504_nand.c
It's a NOOP since 2.6.35.
Signed-off-by: Michael Opdenacker
---
drivers/mtd/nand/hisi504_nand.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/hisi504_nand.c b/drivers/mtd/nand/hisi504_nand.c
index 289ad3ac3e80..e39482441430 100644
--- a/drivers/mtd/nand/hisi504_nand.c
+++ b/drivers/mtd/nand/hisi504_nand.c
@@ -758,7 +758,7 @@ static int hisi_nfc_probe(struct platform_device *pdev)
hisi_nfc_host_init(host);
- ret = devm_request_irq(dev, irq, hinfc_irq_handle, IRQF_DISABLED,
+ ret = devm_request_irq(dev, irq, hinfc_irq_handle, 0,
"nandc", host);
if (ret) {
dev_err(dev, "failed to request IRQ\n");
--
2.1.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 v2 15/16] net: dsa: mv88e6171: Add EEE support to the mv88e6172
From: Andrew Lunn
The mv88e6172 has support for EEE. Check for the product ID and call
the common code if applicable.
Signed-off-by: Andrew Lunn
Reviewed-by: Guenter Roeck
Signed-off-by: Guenter Roeck
---
drivers/net/dsa/mv88e6171.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/net/dsa/mv88e6171.c b/drivers/net/dsa/mv88e6171.c
index 54ebfed1b938..e1700cd8badc 100644
--- a/drivers/net/dsa/mv88e6171.c
+++ b/drivers/net/dsa/mv88e6171.c
@@ -390,6 +390,28 @@ static int mv88e6171_get_sset_count(struct dsa_switch *ds)
return ARRAY_SIZE(mv88e6171_hw_stats);
}
+static int mv88e6171_get_eee(struct dsa_switch *ds, int port,
+struct ethtool_eee *e)
+{
+ struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
+
+ if (ps->id == ID_6172)
+ return mv88e6xxx_get_eee(ds, port, e);
+
+ return -EOPNOTSUPP;
+}
+
+static int mv88e6171_set_eee(struct dsa_switch *ds, int port,
+struct phy_device *phydev, struct ethtool_eee *e)
+{
+ struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
+
+ if (ps->id == ID_6172)
+ return mv88e6xxx_set_eee(ds, port, phydev, e);
+
+ return -EOPNOTSUPP;
+}
+
struct dsa_switch_driver mv88e6171_switch_driver = {
.tag_protocol = DSA_TAG_PROTO_EDSA,
.priv_size = sizeof(struct mv88e6xxx_priv_state),
@@ -402,6 +424,8 @@ struct dsa_switch_driver mv88e6171_switch_driver = {
.get_strings= mv88e6171_get_strings,
.get_ethtool_stats = mv88e6171_get_ethtool_stats,
.get_sset_count = mv88e6171_get_sset_count,
+ .set_eee= mv88e6171_set_eee,
+ .get_eee= mv88e6171_get_eee,
#ifdef CONFIG_NET_DSA_HWMON
.get_temp = mv88e6xxx_get_temp,
#endif
--
2.1.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 v2 12/16] net: dsa: mv88e6352: Add support for ndo_fdb functions
Add support for manipulating switch fdb entries by pointing to the
ndo_fdb functions implemented for mv88e6.
Reviewed-by: Andrew Lunn
Signed-off-by: Guenter Roeck
---
drivers/net/dsa/mv88e6352.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/dsa/mv88e6352.c b/drivers/net/dsa/mv88e6352.c
index 51acd1614ce8..7285bd053363 100644
--- a/drivers/net/dsa/mv88e6352.c
+++ b/drivers/net/dsa/mv88e6352.c
@@ -711,6 +711,9 @@ struct dsa_switch_driver mv88e6352_switch_driver = {
.port_join_bridge = mv88e6xxx_join_bridge,
.port_leave_bridge = mv88e6xxx_leave_bridge,
.port_stp_update= mv88e6xxx_port_stp_update,
+ .fdb_add= mv88e6xxx_port_fdb_add,
+ .fdb_del= mv88e6xxx_port_fdb_del,
+ .fdb_getnext= mv88e6xxx_port_fdb_getnext,
};
MODULE_ALIAS("platform:mv88e6352");
--
2.1.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 v2 09/16] net: dsa: mv88e6352: Add support for hardware bridging
Reviewed-by: Andrew Lunn
Signed-off-by: Guenter Roeck
---
drivers/net/dsa/mv88e6352.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/dsa/mv88e6352.c b/drivers/net/dsa/mv88e6352.c
index f7e7c0f1dff4..51acd1614ce8 100644
--- a/drivers/net/dsa/mv88e6352.c
+++ b/drivers/net/dsa/mv88e6352.c
@@ -708,6 +708,9 @@ struct dsa_switch_driver mv88e6352_switch_driver = {
.set_eeprom = mv88e6352_set_eeprom,
.get_regs_len = mv88e6xxx_get_regs_len,
.get_regs = mv88e6xxx_get_regs,
+ .port_join_bridge = mv88e6xxx_join_bridge,
+ .port_leave_bridge = mv88e6xxx_leave_bridge,
+ .port_stp_update= mv88e6xxx_port_stp_update,
};
MODULE_ALIAS("platform:mv88e6352");
--
2.1.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 v2 13/16] net: dsa: Centralise getting switch id
From: Andrew Lunn Get the switch id and save it away in the private mv88x6xxx structure in a centralised piece of code, rather than each driver doing it itself. Signed-off-by: Andrew Lunn Reviewed-by: Guenter Roeck Signed-off-by: Guenter Roeck --- drivers/net/dsa/mv88e6352.c | 2 -- drivers/net/dsa/mv88e6xxx.c | 2 ++ 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/dsa/mv88e6352.c b/drivers/net/dsa/mv88e6352.c index 7285bd053363..41fe3a6a72d1 100644 --- a/drivers/net/dsa/mv88e6352.c +++ b/drivers/net/dsa/mv88e6352.c @@ -369,8 +369,6 @@ static int mv88e6352_setup(struct dsa_switch *ds) mutex_init(>eeprom_mutex); - ps->id = REG_READ(REG_PORT(0), 0x03) & 0xfff0; - ret = mv88e6352_switch_reset(ds); if (ret < 0) return ret; diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c index 038802229e32..13572cc24c6d 100644 --- a/drivers/net/dsa/mv88e6xxx.c +++ b/drivers/net/dsa/mv88e6xxx.c @@ -1152,6 +1152,8 @@ int mv88e6xxx_setup_common(struct dsa_switch *ds) mutex_init(>stats_mutex); mutex_init(>phy_mutex); + ps->id = REG_READ(REG_PORT(0), 0x03) & 0xfff0; + ps->fid_mask = (1 << DSA_MAX_PORTS) - 1; INIT_WORK(>bridge_work, mv88e6xxx_bridge_work); -- 2.1.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 v2 05/16] net: dsa: mv88e6352: Use common port initialization code
This prepares the driver for hardware bridging. Reviewed-by: Andrew Lunn Signed-off-by: Guenter Roeck --- drivers/net/dsa/mv88e6352.c | 24 +--- 1 file changed, 1 insertion(+), 23 deletions(-) diff --git a/drivers/net/dsa/mv88e6352.c b/drivers/net/dsa/mv88e6352.c index 75cf9e1c5a44..f7e7c0f1dff4 100644 --- a/drivers/net/dsa/mv88e6352.c +++ b/drivers/net/dsa/mv88e6352.c @@ -215,28 +215,6 @@ static int mv88e6352_setup_port(struct dsa_switch *ds, int p) val |= 0x000c; REG_WRITE(addr, 0x04, val); - /* Port Control 1: disable trunking. Also, if this is the -* CPU port, enable learn messages to be sent to this port. -*/ - REG_WRITE(addr, 0x05, dsa_is_cpu_port(ds, p) ? 0x8000 : 0x); - - /* Port based VLAN map: give each port its own address -* database, allow the CPU port to talk to each of the 'real' -* ports, and allow each of the 'real' ports to only talk to -* the upstream port. -*/ - val = (p & 0xf) << 12; - if (dsa_is_cpu_port(ds, p)) - val |= ds->phys_port_mask; - else - val |= 1 << dsa_upstream_port(ds); - REG_WRITE(addr, 0x06, val); - - /* Default VLAN ID and priority: don't set a default VLAN -* ID, and set the default packet priority to zero. -*/ - REG_WRITE(addr, 0x07, 0x); - /* Port Control 2: don't force a good FCS, set the maximum * frame size to 10240 bytes, don't let the switch add or * strip 802.1q tags, don't discard tagged or untagged frames @@ -281,7 +259,7 @@ static int mv88e6352_setup_port(struct dsa_switch *ds, int p) */ REG_WRITE(addr, 0x19, 0x7654); - return 0; + return mv88e6xxx_setup_port_common(ds, p); } #ifdef CONFIG_NET_DSA_HWMON -- 2.1.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 v2 11/16] net: dsa: mv88e6xxx: Add support for fdb_add, fdb_del, and fdb_getnext
No vlan support at this time.
Reviewed-by: Andrew Lunn
Tested-by: Andrew Lunn
Signed-off-by: Guenter Roeck
---
drivers/net/dsa/mv88e6xxx.c | 136
drivers/net/dsa/mv88e6xxx.h | 16 ++
2 files changed, 152 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 17aa74f64233..038802229e32 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -9,6 +9,7 @@
*/
#include
+#include
#include
#include
#include
@@ -953,6 +954,141 @@ int mv88e6xxx_port_stp_update(struct dsa_switch *ds, int
port, u8 state)
return 0;
}
+static int __mv88e6xxx_write_addr(struct dsa_switch *ds,
+ const unsigned char *addr)
+{
+ int i, ret;
+
+ for (i = 0; i < 3; i++) {
+ ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, 0x0d + i,
+ (addr[i * 2] << 8) | addr[i * 2 + 1]);
+ if (ret < 0)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int __mv88e6xxx_read_addr(struct dsa_switch *ds, unsigned char *addr)
+{
+ int i, ret;
+
+ for (i = 0; i < 3; i++) {
+ ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL, 0x0d + i);
+ if (ret < 0)
+ return ret;
+ addr[i * 2] = ret >> 8;
+ addr[i * 2 + 1] = ret & 0xff;
+ }
+
+ return 0;
+}
+
+static int __mv88e6xxx_port_fdb_cmd(struct dsa_switch *ds, int port,
+ const unsigned char *addr, int state)
+{
+ struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
+ u8 fid = ps->fid[port];
+ int ret;
+
+ ret = _mv88e6xxx_atu_wait(ds);
+ if (ret < 0)
+ return ret;
+
+ ret = __mv88e6xxx_write_addr(ds, addr);
+ if (ret < 0)
+ return ret;
+
+ ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, 0x0c,
+ (0x10 << port) | state);
+ if (ret)
+ return ret;
+
+ ret = _mv88e6xxx_atu_cmd(ds, fid, ATU_CMD_LOAD_FID);
+
+ return ret;
+}
+
+int mv88e6xxx_port_fdb_add(struct dsa_switch *ds, int port,
+ const unsigned char *addr, u16 vid)
+{
+ int state = is_multicast_ether_addr(addr) ?
+ FDB_STATE_MC_STATIC : FDB_STATE_STATIC;
+ struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
+ int ret;
+
+ mutex_lock(>smi_mutex);
+ ret = __mv88e6xxx_port_fdb_cmd(ds, port, addr, state);
+ mutex_unlock(>smi_mutex);
+
+ return ret;
+}
+
+int mv88e6xxx_port_fdb_del(struct dsa_switch *ds, int port,
+ const unsigned char *addr, u16 vid)
+{
+ struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
+ int ret;
+
+ mutex_lock(>smi_mutex);
+ ret = __mv88e6xxx_port_fdb_cmd(ds, port, addr, FDB_STATE_UNUSED);
+ mutex_unlock(>smi_mutex);
+
+ return ret;
+}
+
+static int __mv88e6xxx_port_getnext(struct dsa_switch *ds, int port,
+ unsigned char *addr, bool *is_static)
+{
+ struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
+ u8 fid = ps->fid[port];
+ int ret, state;
+
+ ret = _mv88e6xxx_atu_wait(ds);
+ if (ret < 0)
+ return ret;
+
+ ret = __mv88e6xxx_write_addr(ds, addr);
+ if (ret < 0)
+ return ret;
+
+ do {
+ ret = _mv88e6xxx_atu_cmd(ds, fid, ATU_CMD_GETNEXT_FID);
+ if (ret < 0)
+ return ret;
+
+ ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL, 0x0c);
+ if (ret < 0)
+ return ret;
+ state = ret & FDB_STATE_MASK;
+ if (state == FDB_STATE_UNUSED)
+ return -ENOENT;
+ } while (!(((ret >> 4) & 0xff) & (1 << port)));
+
+ ret = __mv88e6xxx_read_addr(ds, addr);
+ if (ret < 0)
+ return ret;
+
+ *is_static = state == (is_multicast_ether_addr(addr) ?
+ FDB_STATE_MC_STATIC : FDB_STATE_STATIC);
+
+ return 0;
+}
+
+/* get next entry for port */
+int mv88e6xxx_port_fdb_getnext(struct dsa_switch *ds, int port,
+ unsigned char *addr, bool *is_static)
+{
+ struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
+ int ret;
+
+ mutex_lock(>smi_mutex);
+ ret = __mv88e6xxx_port_getnext(ds, port, addr, is_static);
+ mutex_unlock(>smi_mutex);
+
+ return ret;
+}
+
static void mv88e6xxx_bridge_work(struct work_struct *work)
{
struct mv88e6xxx_priv_state *ps;
diff --git a/drivers/net/dsa/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx.h
index 8e215ebc8d34..aaf239aba726 100644
--- a/drivers/net/dsa/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx.h
@@ -19,6 +19,8 @@
#define ATU_BUSY 0x8000
+#define ATU_CMD_LOAD_FID
[PATCH v2 03/16] net: dsa: mv88e6xxx: Disable Message Port bit for CPU port
Datasheet says that the Message Port bit should not be set for the CPU port. Having it set causes DSA tagged packets to be sent to the CPU port roughly every 30 seconds. Those packets are the same as real packets forwarded between switch ports if the switch is configured for switching between multiple ports. The packets are then bridged by the software bridge, resulting in duplicated packets on the network. Reported-by: Andrew Lunn Cc: Andrew Lunn Reviewed-by: Andrew Lunn Tested-by: Andrew Lunn Signed-off-by: Guenter Roeck --- drivers/net/dsa/mv88e6xxx.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c index 2052e51edd5d..5da50b00fdf6 100644 --- a/drivers/net/dsa/mv88e6xxx.c +++ b/drivers/net/dsa/mv88e6xxx.c @@ -707,11 +707,10 @@ int mv88e6xxx_setup_port_common(struct dsa_switch *ds, int port) mutex_lock(>smi_mutex); - /* Port Control 1: disable trunking. Also, if this is the -* CPU port, enable learn messages to be sent to this port. + /* Port Control 1: disable trunking, disable sending +* learning messages to this port. */ - ret = _mv88e6xxx_reg_write(ds, REG_PORT(port), 0x05, - dsa_is_cpu_port(ds, port) ? 0x8000 : 0x); + ret = _mv88e6xxx_reg_write(ds, REG_PORT(port), 0x05, 0x); if (ret) goto abort; -- 2.1.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 v2 16/16] net: dsa: mv88e6171: Add support for hardware bridging
From: Andrew Lunn
Wire up the common code for setting up hardware bridging
and access to the forwarding database.
Signed-off-by: Andrew Lunn
Signed-off-by: Guenter Roeck
---
drivers/net/dsa/mv88e6171.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/dsa/mv88e6171.c b/drivers/net/dsa/mv88e6171.c
index e1700cd8badc..18cfead83dc9 100644
--- a/drivers/net/dsa/mv88e6171.c
+++ b/drivers/net/dsa/mv88e6171.c
@@ -431,6 +431,12 @@ struct dsa_switch_driver mv88e6171_switch_driver = {
#endif
.get_regs_len = mv88e6xxx_get_regs_len,
.get_regs = mv88e6xxx_get_regs,
+ .port_join_bridge = mv88e6xxx_join_bridge,
+ .port_leave_bridge = mv88e6xxx_leave_bridge,
+ .port_stp_update= mv88e6xxx_port_stp_update,
+ .fdb_add= mv88e6xxx_port_fdb_add,
+ .fdb_del= mv88e6xxx_port_fdb_del,
+ .fdb_getnext= mv88e6xxx_port_fdb_getnext,
};
MODULE_ALIAS("platform:mv88e6171");
--
2.1.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 v2 10/16] net: dsa: Add basic framework to support ndo_fdb functions
Provide callbacks for ndo_fdb_add, ndo_fdb_del, and ndo_fdb_dump.
Reviewed-by: Andrew Lunn
Tested-by: Andrew Lunn
Signed-off-by: Guenter Roeck
---
include/net/dsa.h | 6
net/dsa/slave.c | 102 ++
2 files changed, 108 insertions(+)
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 47917e5e1e12..fbca63ba8f73 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -296,6 +296,12 @@ struct dsa_switch_driver {
u32 br_port_mask);
int (*port_stp_update)(struct dsa_switch *ds, int port,
u8 state);
+ int (*fdb_add)(struct dsa_switch *ds, int port,
+ const unsigned char *addr, u16 vid);
+ int (*fdb_del)(struct dsa_switch *ds, int port,
+ const unsigned char *addr, u16 vid);
+ int (*fdb_getnext)(struct dsa_switch *ds, int port,
+ unsigned char *addr, bool *is_static);
};
void register_switch_driver(struct dsa_switch_driver *type);
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 39555f3f263b..3597724ec3d8 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -201,6 +201,105 @@ out:
return 0;
}
+static int dsa_slave_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
+struct net_device *dev,
+const unsigned char *addr, u16 vid, u16 nlm_flags)
+{
+ struct dsa_slave_priv *p = netdev_priv(dev);
+ struct dsa_switch *ds = p->parent;
+ int ret = -EOPNOTSUPP;
+
+ if (ds->drv->fdb_add)
+ ret = ds->drv->fdb_add(ds, p->port, addr, vid);
+
+ return ret;
+}
+
+static int dsa_slave_fdb_del(struct ndmsg *ndm, struct nlattr *tb[],
+struct net_device *dev,
+const unsigned char *addr, u16 vid)
+{
+ struct dsa_slave_priv *p = netdev_priv(dev);
+ struct dsa_switch *ds = p->parent;
+ int ret = -EOPNOTSUPP;
+
+ if (ds->drv->fdb_del)
+ ret = ds->drv->fdb_del(ds, p->port, addr, vid);
+
+ return ret;
+}
+
+static int dsa_slave_fill_info(struct net_device *dev, struct sk_buff *skb,
+ const unsigned char *addr, u16 vid,
+ bool is_static,
+ u32 portid, u32 seq, int type,
+ unsigned int flags)
+{
+ struct nlmsghdr *nlh;
+ struct ndmsg *ndm;
+
+ nlh = nlmsg_put(skb, portid, seq, type, sizeof(*ndm), flags);
+ if (!nlh)
+ return -EMSGSIZE;
+
+ ndm = nlmsg_data(nlh);
+ ndm->ndm_family = AF_BRIDGE;
+ ndm->ndm_pad1= 0;
+ ndm->ndm_pad2= 0;
+ ndm->ndm_flags = NTF_EXT_LEARNED;
+ ndm->ndm_type= 0;
+ ndm->ndm_ifindex = dev->ifindex;
+ ndm->ndm_state = is_static ? NUD_NOARP : NUD_REACHABLE;
+
+ if (nla_put(skb, NDA_LLADDR, ETH_ALEN, addr))
+ goto nla_put_failure;
+
+ if (vid && nla_put_u16(skb, NDA_VLAN, vid))
+ goto nla_put_failure;
+
+ nlmsg_end(skb, nlh);
+ return 0;
+
+nla_put_failure:
+ nlmsg_cancel(skb, nlh);
+ return -EMSGSIZE;
+}
+
+/* Dump information about entries, in response to GETNEIGH */
+static int dsa_slave_fdb_dump(struct sk_buff *skb, struct netlink_callback *cb,
+ struct net_device *dev,
+ struct net_device *filter_dev, int idx)
+{
+ struct dsa_slave_priv *p = netdev_priv(dev);
+ struct dsa_switch *ds = p->parent;
+ unsigned char addr[ETH_ALEN] = { 0 };
+ int ret;
+
+ if (!ds->drv->fdb_getnext)
+ return -EOPNOTSUPP;
+
+ for (; ; idx++) {
+ bool is_static;
+
+ ret = ds->drv->fdb_getnext(ds, p->port, addr, _static);
+ if (ret < 0)
+ break;
+
+ if (idx < cb->args[0])
+ continue;
+
+ ret = dsa_slave_fill_info(dev, skb, addr, 0,
+ is_static,
+ NETLINK_CB(cb->skb).portid,
+ cb->nlh->nlmsg_seq,
+ RTM_NEWNEIGH, NLM_F_MULTI);
+ if (ret < 0)
+ break;
+ }
+
+ return idx;
+}
+
static int dsa_slave_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
{
struct dsa_slave_priv *p = netdev_priv(dev);
@@ -572,6 +671,9 @@ static const struct net_device_ops dsa_slave_netdev_ops = {
.ndo_change_rx_flags= dsa_slave_change_rx_flags,
.ndo_set_rx_mode= dsa_slave_set_rx_mode,
.ndo_set_mac_address= dsa_slave_set_mac_address,
+ .ndo_fdb_add= dsa_slave_fdb_add,
+ .ndo_fdb_del= dsa_slave_fdb_del,
+
[PATCH v2 14/16] net: dsa: mv88e6171: Add defines for switch product IDs
From: Andrew Lunn
Make the code more readable by using defines for the switch IDs.
Signed-off-by: Andrew Lunn
Reviewed-by: Guenter Roeck
Signed-off-by: Guenter Roeck
---
drivers/net/dsa/mv88e6171.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dsa/mv88e6171.c b/drivers/net/dsa/mv88e6171.c
index 6ce6a3ea1b8d..54ebfed1b938 100644
--- a/drivers/net/dsa/mv88e6171.c
+++ b/drivers/net/dsa/mv88e6171.c
@@ -17,6 +17,10 @@
#include
#include "mv88e6xxx.h"
+/* Switch product IDs */
+#define ID_61710x1710
+#define ID_61720x1720
+
static char *mv88e6171_probe(struct device *host_dev, int sw_addr)
{
struct mii_bus *bus = dsa_host_dev_to_mii_bus(host_dev);
@@ -27,9 +31,9 @@ static char *mv88e6171_probe(struct device *host_dev, int
sw_addr)
ret = __mv88e6xxx_reg_read(bus, sw_addr, REG_PORT(0), 0x03);
if (ret >= 0) {
- if ((ret & 0xfff0) == 0x1710)
+ if ((ret & 0xfff0) == ID_6171)
return "Marvell 88E6171";
- if ((ret & 0xfff0) == 0x1720)
+ if ((ret & 0xfff0) == ID_6172)
return "Marvell 88E6172";
}
--
2.1.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] MIPS: Loongson-3: remove deprecated IRQF_DISABLED
This removes the use of the IRQF_DISABLED flag
from arch/mips/loongson/loongson-3/hpet.c
It's a NOOP since 2.6.35.
Signed-off-by: Michael Opdenacker
---
arch/mips/loongson/loongson-3/hpet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/loongson/loongson-3/hpet.c
b/arch/mips/loongson/loongson-3/hpet.c
index e898d68668a9..5c21cd3bd339 100644
--- a/arch/mips/loongson/loongson-3/hpet.c
+++ b/arch/mips/loongson/loongson-3/hpet.c
@@ -162,7 +162,7 @@ static irqreturn_t hpet_irq_handler(int irq, void *data)
static struct irqaction hpet_irq = {
.handler = hpet_irq_handler,
- .flags = IRQF_DISABLED | IRQF_NOBALANCING | IRQF_TIMER,
+ .flags = IRQF_NOBALANCING | IRQF_TIMER,
.name = "hpet",
};
--
2.1.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 7/7] x86/intel_rdt: Add CAT documentation and usage guide
On Thu, Mar 26, 2015 at 11:38:59AM -0700, Vikas Shivappa wrote: > > Hello Marcelo, Hi Vikas, > On Wed, 25 Mar 2015, Marcelo Tosatti wrote: > > >On Thu, Mar 12, 2015 at 04:16:07PM -0700, Vikas Shivappa wrote: > >>This patch adds a description of Cache allocation technology, overview > >>of kernel implementation and usage of CAT cgroup interface. > >> > >>Signed-off-by: Vikas Shivappa > >>--- > >> Documentation/cgroups/rdt.txt | 183 > >> ++ > >> 1 file changed, 183 insertions(+) > >> create mode 100644 Documentation/cgroups/rdt.txt > >> > >>diff --git a/Documentation/cgroups/rdt.txt b/Documentation/cgroups/rdt.txt > >>new file mode 100644 > >>index 000..98eb4b8 > >>--- /dev/null > >>+++ b/Documentation/cgroups/rdt.txt > >>@@ -0,0 +1,183 @@ > >>+RDT > >>+--- > >>+ > >>+Copyright (C) 2014 Intel Corporation > >>+Written by vikas.shiva...@linux.intel.com > >>+(based on contents and format from cpusets.txt) > >>+ > >>+CONTENTS: > >>+= > >>+ > >>+1. Cache Allocation Technology > >>+ 1.1 What is RDT and CAT ? > >>+ 1.2 Why is CAT needed ? > >>+ 1.3 CAT implementation overview > >>+ 1.4 Assignment of CBM and CLOS > >>+ 1.5 Scheduling and Context Switch > >>+2. Usage Examples and Syntax > >>+ > >>+1. Cache Allocation Technology(CAT) > >>+=== > >>+ > >>+1.1 What is RDT and CAT > >>+--- > >>+ > >>+CAT is a part of Resource Director Technology(RDT) or Platform Shared > >>+resource control which provides support to control Platform shared > >>+resources like cache. Currently Cache is the only resource that is > >>+supported in RDT. > >>+More information can be found in the Intel SDM section 17.15. > >>+ > >>+Cache Allocation Technology provides a way for the Software (OS/VMM) > >>+to restrict cache allocation to a defined 'subset' of cache which may > >>+be overlapping with other 'subsets'. This feature is used when > >>+allocating a line in cache ie when pulling new data into the cache. > >>+The programming of the h/w is done via programming MSRs. > >>+ > >>+The different cache subsets are identified by CLOS identifier (class > >>+of service) and each CLOS has a CBM (cache bit mask). The CBM is a > >>+contiguous set of bits which defines the amount of cache resource that > >>+is available for each 'subset'. > >>+ > >>+1.2 Why is CAT needed > >>+- > >>+ > >>+The CAT enables more cache resources to be made available for higher > >>+priority applications based on guidance from the execution > >>+environment. > >>+ > >>+The architecture also allows dynamically changing these subsets during > >>+runtime to further optimize the performance of the higher priority > >>+application with minimal degradation to the low priority app. > >>+Additionally, resources can be rebalanced for system throughput > >>+benefit. (Refer to Section 17.15 in the Intel SDM) > >>+ > >>+This technique may be useful in managing large computer systems which > >>+large LLC. Examples may be large servers running instances of > >>+webservers or database servers. In such complex systems, these subsets > >>+can be used for more careful placing of the available cache > >>+resources. > >>+ > >>+The CAT kernel patch would provide a basic kernel framework for users > >>+to be able to implement such cache subsets. > >>+ > >>+1.3 CAT implementation Overview > >>+--- > >>+ > >>+Kernel implements a cgroup subsystem to support cache allocation. > >>+ > >>+Each cgroup has a CLOSid <-> CBM(cache bit mask) mapping. > >>+A CLOS(Class of service) is represented by a CLOSid.CLOSid is internal > >>+to the kernel and not exposed to user. Each cgroup would have one CBM > >>+and would just represent one cache 'subset'. > >>+ > >>+The cgroup follows cgroup hierarchy ,mkdir and adding tasks to the > >>+cgroup never fails. When a child cgroup is created it inherits the > >>+CLOSid and the CBM from its parent. When a user changes the default > >>+CBM for a cgroup, a new CLOSid may be allocated if the CBM was not > >>+used before. The changing of 'cbm' may fail with -ERRNOSPC once the > >>+kernel runs out of maximum CLOSids it can support. > >>+User can create as many cgroups as he wants but having different CBMs > >>+at the same time is restricted by the maximum number of CLOSids > >>+(multiple cgroups can have the same CBM). > >>+Kernel maintains a CLOSid<->cbm mapping which keeps reference counter > >>+for each cgroup using a CLOSid. > >>+ > >>+The tasks in the cgroup would get to fill the LLC cache represented by > >>+the cgroup's 'cbm' file. > >>+ > >>+Root directory would have all available bits set in 'cbm' file by > >>+default. > >>+ > >>+1.4 Assignment of CBM,CLOS > >>+-- > >>+ > >>+The 'cbm' needs to be a subset of the parent node's 'cbm'. > >>+Any contiguous subset of these bits(with a minimum of 2 bits) maybe > >>+set to indicate the cache mapping desired.
Re: [PATCH] leds-gpio: Fix error handling and memory leak
On Mon, Mar 9, 2015 at 5:43 PM, wrote:
> From: Corey Minyard
>
> The leds-gpio driver would not clean up properly if it failed in some
> places, and it wasn't freeing its private data.
>
> Signed-off-by: Corey Minyard
> ---
> drivers/leds/leds-gpio.c | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
> index d26af0a..32f7642 100644
> --- a/drivers/leds/leds-gpio.c
> +++ b/drivers/leds/leds-gpio.c
> @@ -198,8 +198,10 @@ static struct gpio_leds_priv *gpio_leds_create(struct
> platform_device *pdev)
> } else {
> if (IS_ENABLED(CONFIG_OF) && !led.name && np)
> led.name = np->name;
> - if (!led.name)
> - return ERR_PTR(-EINVAL);
> + if (!led.name) {
> + ret = -EINVAL;
> + goto err;
> + }
> }
> fwnode_property_read_string(child, "linux,default-trigger",
> _trigger);
> @@ -217,19 +219,21 @@ static struct gpio_leds_priv *gpio_leds_create(struct
> platform_device *pdev)
> if (fwnode_property_present(child, "retain-state-suspended"))
> led.retain_state_suspended = 1;
>
> - ret = create_gpio_led(, >leds[priv->num_leds++],
> + ret = create_gpio_led(, >leds[priv->num_leds],
Why need this change? it's correct. And your add one more line
"priv->num_leds++"
> dev, NULL);
> if (ret < 0) {
> fwnode_handle_put(child);
> goto err;
> }
> + priv->num_leds++;
Why need this?
> }
>
> return priv;
>
> err:
> - for (count = priv->num_leds - 2; count >= 0; count--)
> + for (count = priv->num_leds - 1; count >= 0; count--)
> delete_gpio_led(>leds[count]);
> + devm_kfree(dev, priv);
priv is created by devm_kzalloc(), so if driver probing return error,
it will be freed automatically, you don't need call devm_free();
> return ERR_PTR(ret);
> }
>
> @@ -283,6 +287,7 @@ static int gpio_led_remove(struct platform_device *pdev)
>
> for (i = 0; i < priv->num_leds; i++)
> delete_gpio_led(>leds[i]);
> + devm_kfree(>dev, priv);
No need this during remove.
>
> return 0;
> }
> --
> 1.8.3.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-leds" 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/
Re: [PATCH v4 14/15] ASoC: rockchip/rockchip-hdmi-audio: add sound driver for hdmi audio
On Fri, Mar 27, 2015 at 09:16:17AM +0800, yakir wrote:
> On 2015年03月27日 02:16, Mark Brown wrote:
> >>+free_cpu_of_node:
> >>+ hdmi_audio_dai.cpu_of_node = NULL;
> >>+ hdmi_audio_dai.platform_of_node = NULL;
> >>+free_priv_data:
> >>+ snd_soc_card_set_drvdata(card, NULL);
> >>+ platform_set_drvdata(pdev, NULL);
> >>+ card->dev = NULL;
> >If any of these assignments is doing anything there's a problem with the
> >code.
> Yes, when probe failed, program will goto this code.
You're missing the point, these don't do anything useful.
> >>+{
> >>+ struct snd_soc_card *card = platform_get_drvdata(pdev);
> >>+
> >>+ snd_soc_unregister_card(card);
> >devm_snd_soc_register_card() and you can remove this function entirely.
> do you mean that when I take devm_snd_soc_register_card() to register card,
> then I do not need unregister card any more(destroy with device) ?
Yes, that is the whole point of the devm_ APIs.
signature.asc
Description: Digital signature
[PATCH] [RESEND][SCSI] ips: remove unused defines
This patch removes unused defines from drivers/scsi/ips.h - the min() macro is not used - the __iomem define is no longer needed to compile ips.c without warnings Signed-off-by: Michael Opdenacker --- drivers/scsi/ips.h | 8 1 file changed, 8 deletions(-) diff --git a/drivers/scsi/ips.h b/drivers/scsi/ips.h index 45b9566b928e..26df4f6e9d70 100644 --- a/drivers/scsi/ips.h +++ b/drivers/scsi/ips.h @@ -88,14 +88,6 @@ touch_nmi_watchdog(); \ } while (0) - #ifndef min - #define min(x,y) ((x) < (y) ? x : y) - #endif - - #ifndef __iomem /* For clean compiles in earlier kernels without __iomem annotations */ - #define __iomem - #endif - #define pci_dma_hi32(a) ((a >> 16) >> 16) #define pci_dma_lo32(a) (a & 0x) -- 2.1.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 v4 14/15] ASoC: rockchip/rockchip-hdmi-audio: add sound driver for hdmi audio
Hi Mark,
On 2015年03月27日 02:16, Mark Brown wrote:
On Sat, Feb 28, 2015 at 10:04:30PM -0500, Yakir Yang wrote:
+ ret = snd_soc_dai_set_fmt(cpu_dai, dai_fmt);
+ if (ret < 0) {
+ dev_err(cpu_dai->dev, "failed to set cpu_dai fmt.\n");
+ return ret;
+ }
You've already set this in the dai_link, no need to do it again.
Okay, correct it in next v5.
+ dev_info(>dev, "hdmi audio init success.\n");
Please remove noisy prints like this.
Okay, turn it to dev_debug(...)
+free_cpu_of_node:
+ hdmi_audio_dai.cpu_of_node = NULL;
+ hdmi_audio_dai.platform_of_node = NULL;
+free_priv_data:
+ snd_soc_card_set_drvdata(card, NULL);
+ platform_set_drvdata(pdev, NULL);
+ card->dev = NULL;
If any of these assignments is doing anything there's a problem with the
code.
Yes, when probe failed, program will goto this code.
+{
+ struct snd_soc_card *card = platform_get_drvdata(pdev);
+
+ snd_soc_unregister_card(card);
devm_snd_soc_register_card() and you can remove this function entirely.
do you mean that when I take devm_snd_soc_register_card() to register card,
then I do not need unregister card any more(destroy with device) ?
+static const struct of_device_id rockchip_hdmi_audio_of_match[] = {
+ { .compatible = "rockchip,rk3288-hdmi-audio", },
+ {},
+};
There is no documentation for this binding, binding documentation is
mandatory. Based on the compatible string this looks like it's specific
to the SoC rather than a design for a board - is the whole card part of
the SoC?
It's my fault, cause the dts patch have not CC you, I will correct it in
next v5
Thanks :)
Yakir
--
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] [RESEND] drivers: bus: omap_l3: remove deprecated IRQF_DISABLED
This patch removes the use of the IRQF_DISABLED flag
from drivers/bus/omap_l3_*
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
Acked-by: Santosh Shilimkar
---
drivers/bus/omap_l3_noc.c | 4 ++--
drivers/bus/omap_l3_smx.c | 6 ++
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index 029bc73de001..602298b527e8 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -284,7 +284,7 @@ static int omap_l3_probe(struct platform_device *pdev)
*/
l3->debug_irq = platform_get_irq(pdev, 0);
ret = devm_request_irq(l3->dev, l3->debug_irq, l3_interrupt_handler,
- IRQF_DISABLED, "l3-dbg-irq", l3);
+ 0, "l3-dbg-irq", l3);
if (ret) {
dev_err(l3->dev, "request_irq failed for %d\n",
l3->debug_irq);
@@ -293,7 +293,7 @@ static int omap_l3_probe(struct platform_device *pdev)
l3->app_irq = platform_get_irq(pdev, 1);
ret = devm_request_irq(l3->dev, l3->app_irq, l3_interrupt_handler,
- IRQF_DISABLED, "l3-app-irq", l3);
+ 0, "l3-app-irq", l3);
if (ret)
dev_err(l3->dev, "request_irq failed for %d\n", l3->app_irq);
diff --git a/drivers/bus/omap_l3_smx.c b/drivers/bus/omap_l3_smx.c
index 597fdaee7315..0b07895f2eb4 100644
--- a/drivers/bus/omap_l3_smx.c
+++ b/drivers/bus/omap_l3_smx.c
@@ -252,8 +252,7 @@ static int omap3_l3_probe(struct platform_device *pdev)
l3->debug_irq = platform_get_irq(pdev, 0);
ret = request_irq(l3->debug_irq, omap3_l3_app_irq,
- IRQF_DISABLED | IRQF_TRIGGER_RISING,
- "l3-debug-irq", l3);
+ IRQF_TRIGGER_RISING, "l3-debug-irq", l3);
if (ret) {
dev_err(>dev, "couldn't request debug irq\n");
goto err1;
@@ -261,8 +260,7 @@ static int omap3_l3_probe(struct platform_device *pdev)
l3->app_irq = platform_get_irq(pdev, 1);
ret = request_irq(l3->app_irq, omap3_l3_app_irq,
- IRQF_DISABLED | IRQF_TRIGGER_RISING,
- "l3-app-irq", l3);
+ IRQF_TRIGGER_RISING, "l3-app-irq", l3);
if (ret) {
dev_err(>dev, "couldn't request app irq\n");
goto err2;
--
2.1.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] [RESEND] cpqarray: remove deprecated IRQF_DISABLED
This patch removes the use of the IRQF_DISABLED flag
from drivers/block/cpqarray.c
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/block/cpqarray.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/cpqarray.c b/drivers/block/cpqarray.c
index 2b9440384536..370721ea27ca 100644
--- a/drivers/block/cpqarray.c
+++ b/drivers/block/cpqarray.c
@@ -406,7 +406,7 @@ static int cpqarray_register_ctlr(int i, struct pci_dev
*pdev)
}
hba[i]->access.set_intr_mask(hba[i], 0);
if (request_irq(hba[i]->intr, do_ida_intr,
- IRQF_DISABLED|IRQF_SHARED, hba[i]->devname, hba[i]))
+ IRQF_SHARED, hba[i]->devname, hba[i]))
{
printk(KERN_ERR "cpqarray: Unable to get irq %d for %s\n",
hba[i]->intr, hba[i]->devname);
--
2.1.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: [RFCv2] mm: page allocation for less fragmentation
2015-03-26 오후 7:28에 Mel Gorman 이(가) 쓴 글: On Thu, Mar 26, 2015 at 06:16:22AM +0900, Gioh Kim wrote: 2015-03-25 ?? 7:56??? Mel Gorman ???(???) ??? ???: On Wed, Mar 25, 2015 at 11:39:15AM +0900, Gioh Kim wrote: My driver allocates more than 40MB pages via alloc_page() at a time and maps them at virtual address. Totally it uses 300~400MB pages. If I run a heavy load test for a few days in 1GB memory system, I cannot allocate even order=3 pages because-of the external fragmentation. I thought I needed a anti-fragmentation solution for my driver. But there is no allocation function that considers fragmentation. The compaction is not helpful because it is only for movable pages, not unmovable pages. This patch proposes a allocation function allocates only pages in the same pageblock. Is this not what CMA is for? Or creating a MOVABLE zone? It's not related to CMA and MOVABLE zone. It's for compaction and anti-fragmentation for any zone. Create a CMA area, allow your driver to use it use alloc_contig_range. As it is, this is creating another contiguous range allocation function with no in-kernel users. I'm sorry but I cannot follow your point. I think this is not contiguous range allocation. And CMA is not suitable for my driver because it needs fast allocation. I can move pages into CMA area if I need high-order pages. But the pages are unmovable types so it would pin the CMA area. Please let me explain my problem again. I've been suffering for years from fragmentation via unmovable pages. Many of them are via graphic driver such as gpu and coder/decoder. Current kernel compaction is not sufficient with this situation. Graphic memory of the embedded systems like TV, phone I'm working for is getting bigger. For instance my platform has 1GB and 300MB~400MB are consumed for graphic processing. There are two reason: 1. cpu and gpu share memory 2. screen size(resolution) is getting bigger so that icon and ux images also are getting bigger Therefore I don't need any contigous pages, but less fragmentation page allocation for unmovable pages. -- 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] [RESEND] aic7xxx: replace kmalloc/memset by kzalloc
This replaces kmalloc + memset by a call to kzalloc
This also fixes one checkpatch.pl issue in the process.
This improvement was suggested by "make coccicheck"
Signed-off-by: Michael Opdenacker
Reviewed-by: Hannes Reinecke
---
drivers/scsi/aic7xxx/aic79xx_core.c | 3 +--
drivers/scsi/aic7xxx/aic79xx_osm.c | 3 +--
drivers/scsi/aic7xxx/aic7xxx_core.c | 10 --
drivers/scsi/aic7xxx/aic7xxx_osm.c | 3 +--
4 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/scsi/aic7xxx/aic79xx_core.c
b/drivers/scsi/aic7xxx/aic79xx_core.c
index 97f2accd3dbb..109e2c99e6c1 100644
--- a/drivers/scsi/aic7xxx/aic79xx_core.c
+++ b/drivers/scsi/aic7xxx/aic79xx_core.c
@@ -10437,14 +10437,13 @@ ahd_handle_en_lun(struct ahd_softc *ahd, struct
cam_sim *sim, union ccb *ccb)
return;
}
}
- lstate = kmalloc(sizeof(*lstate), GFP_ATOMIC);
+ lstate = kzalloc(sizeof(*lstate), GFP_ATOMIC);
if (lstate == NULL) {
xpt_print_path(ccb->ccb_h.path);
printk("Couldn't allocate lstate\n");
ccb->ccb_h.status = CAM_RESRC_UNAVAIL;
return;
}
- memset(lstate, 0, sizeof(*lstate));
status = xpt_create_path(>path, /*periph*/NULL,
xpt_path_path_id(ccb->ccb_h.path),
xpt_path_target_id(ccb->ccb_h.path),
diff --git a/drivers/scsi/aic7xxx/aic79xx_osm.c
b/drivers/scsi/aic7xxx/aic79xx_osm.c
index d5c7b193d8d3..ce96a0be3282 100644
--- a/drivers/scsi/aic7xxx/aic79xx_osm.c
+++ b/drivers/scsi/aic7xxx/aic79xx_osm.c
@@ -1326,10 +1326,9 @@ int
ahd_platform_alloc(struct ahd_softc *ahd, void *platform_arg)
{
ahd->platform_data =
- kmalloc(sizeof(struct ahd_platform_data), GFP_ATOMIC);
+ kzalloc(sizeof(struct ahd_platform_data), GFP_ATOMIC);
if (ahd->platform_data == NULL)
return (ENOMEM);
- memset(ahd->platform_data, 0, sizeof(struct ahd_platform_data));
ahd->platform_data->irq = AHD_LINUX_NOIRQ;
ahd_lockinit(ahd);
ahd->seltime = (aic79xx_seltime & 0x3) << 4;
diff --git a/drivers/scsi/aic7xxx/aic7xxx_core.c
b/drivers/scsi/aic7xxx/aic7xxx_core.c
index 10172a3af1b9..c4829d84b335 100644
--- a/drivers/scsi/aic7xxx/aic7xxx_core.c
+++ b/drivers/scsi/aic7xxx/aic7xxx_core.c
@@ -4464,10 +4464,9 @@ ahc_softc_init(struct ahc_softc *ahc)
ahc->pause = ahc->unpause | PAUSE;
/* XXX The shared scb data stuff should be deprecated */
if (ahc->scb_data == NULL) {
- ahc->scb_data = kmalloc(sizeof(*ahc->scb_data), GFP_ATOMIC);
+ ahc->scb_data = kzalloc(sizeof(*ahc->scb_data), GFP_ATOMIC);
if (ahc->scb_data == NULL)
return (ENOMEM);
- memset(ahc->scb_data, 0, sizeof(*ahc->scb_data));
}
return (0);
@@ -4780,10 +4779,10 @@ ahc_init_scbdata(struct ahc_softc *ahc)
SLIST_INIT(_data->sg_maps);
/* Allocate SCB resources */
- scb_data->scbarray = kmalloc(sizeof(struct scb) * AHC_SCB_MAX_ALLOC,
GFP_ATOMIC);
+ scb_data->scbarray = kzalloc(sizeof(struct scb) * AHC_SCB_MAX_ALLOC,
+ GFP_ATOMIC);
if (scb_data->scbarray == NULL)
return (ENOMEM);
- memset(scb_data->scbarray, 0, sizeof(struct scb) * AHC_SCB_MAX_ALLOC);
/* Determine the number of hardware SCBs and initialize them */
@@ -7558,14 +7557,13 @@ ahc_handle_en_lun(struct ahc_softc *ahc, struct cam_sim
*sim, union ccb *ccb)
return;
}
}
- lstate = kmalloc(sizeof(*lstate), GFP_ATOMIC);
+ lstate = kzalloc(sizeof(*lstate), GFP_ATOMIC);
if (lstate == NULL) {
xpt_print_path(ccb->ccb_h.path);
printk("Couldn't allocate lstate\n");
ccb->ccb_h.status = CAM_RESRC_UNAVAIL;
return;
}
- memset(lstate, 0, sizeof(*lstate));
status = xpt_create_path(>path, /*periph*/NULL,
xpt_path_path_id(ccb->ccb_h.path),
xpt_path_target_id(ccb->ccb_h.path),
diff --git a/drivers/scsi/aic7xxx/aic7xxx_osm.c
b/drivers/scsi/aic7xxx/aic7xxx_osm.c
index 88360116dbcb..a2f2c774cd6b 100644
--- a/drivers/scsi/aic7xxx/aic7xxx_osm.c
+++ b/drivers/scsi/aic7xxx/aic7xxx_osm.c
@@ -1214,10 +1214,9 @@ ahc_platform_alloc(struct ahc_softc *ahc, void
*platform_arg)
{
ahc->platform_data =
- kmalloc(sizeof(struct ahc_platform_data), GFP_ATOMIC);
+ kzalloc(sizeof(struct ahc_platform_data), GFP_ATOMIC);
if (ahc->platform_data == NULL)
return
Re: missing MS_RDONLY check in fsync
Hi Sanidhya, you might be interested in the following patch by Richard Yao: http://marc.info/?l=linux-fsdevel=141523828324345=2 [PATCH v4 1/1] vfs: Respect MS_RDONLY at bind mount creation Regards Matt -- 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 1/2] spi/rockchip: Round up clock rate divisor to err on the safe side
On Thu, Mar 26, 2015 at 04:30:24PM -0700, Julius Werner wrote: > The Rockchip SPI driver currently calculates its clock rate divisor by > integer dividing the parent rate by the target rate, and then rounding > the result up to the next even number (since the divisor must be > even). Applied both, thanks. signature.asc Description: Digital signature
Kernel warning at fs/btrfs/inode.c:8693 btrfs_destroy_inode+0x1fa/0x2a0 [btrfs]()
Hello, I'm running 4.0-rc3, and I'm regularly getting these warnings in my kernel log: Mar 26 17:31:13 vostro kernel: [21480.088671] [ cut here ] Mar 26 17:31:13 vostro kernel: [21480.088682] WARNING: CPU: 0 PID: 28958 at fs/btrfs/inode.c:8693 btrfs_destroy_inode+0x1fa/0x2a0 [btrfs]() Mar 26 17:31:13 vostro kernel: [21480.088682] Modules linked in: hmac can_bcm sctp libcrc32c rds can_raw can binfmt_misc bridge stp llc tun ext4 crc16 mbcache jbd2 eeepc_wmi asus_wmi sparse_keymap rfkill mxm_wmi iTCO_wdt iTCO_vendor_support x86_pkg_temp_thermal mei_me intel_powerclamp psmouse intel_rapl lpc_ich pcspkr serio_raw iosf_mbi snd_hda_codec_hdmi mei snd_hda_codec_realtek snd_hda_codec_generic i2c_i801 mfd_core snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm snd_timer snd soundcore battery shpchp processor evdev wmi nct6775 hwmon_vid coretemp kvm_intel kvm loop fuse parport_pc ppdev lp parport autofs4 btrfs xor raid6_pq sha256_ssse3 sha256_generic algif_skcipher af_alg dm_crypt dm_mod hid_generic usbhid usb_storage hid sr_mod cdrom sg sd_mod crct10dif_pclmul crc32_pclmul ahci xhci_pci i915 crc32c_intel ehci_pci e1000e i2c_algo_bit xhci_hcd ehci_hcd libahci ghash_clmulni_intel ptp libata aesni_intel aes_x86_64 lrw gf128mul pps_core glue_helper drm_kms_helper usbcore ablk_helper scsi_mod cryptd usb_common drm thermal i2c_core fan video thermal_sys button Mar 26 17:31:13 vostro kernel: [21480.088729] CPU: 0 PID: 28958 Comm: python3 Tainted: GW 4.0.0-rc3 #2 Mar 26 17:31:13 vostro kernel: [21480.088730] Hardware name: System manufacturer System Product Name/P8Z68-V GEN3, BIOS 3603 11/09/2012 Mar 26 17:31:13 vostro kernel: [21480.088730] a055e547 81553b12 Mar 26 17:31:13 vostro kernel: [21480.088733] 8106bfb1 88020ed68f18 88019a1b91b8 880222b13000 Mar 26 17:31:13 vostro kernel: [21480.088734] 88019a1b91b8 8802248918b0 a04edf7a 88019a1b91b8 Mar 26 17:31:13 vostro kernel: [21480.088736] Call Trace: Mar 26 17:31:13 vostro kernel: [21480.088737] [] ? dump_stack+0x40/0x50 Mar 26 17:31:13 vostro kernel: [21480.088740] [] ? warn_slowpath_common+0x81/0xb0 Mar 26 17:31:13 vostro kernel: [21480.088743] [] ? btrfs_destroy_inode+0x1fa/0x2a0 [btrfs] Mar 26 17:31:13 vostro kernel: [21480.088751] [] ? __dentry_kill+0x180/0x1f0 Mar 26 17:31:13 vostro kernel: [21480.088752] [] ? dput+0x127/0x220 Mar 26 17:31:13 vostro kernel: [21480.088754] [] ? __fput+0x166/0x1e0 Mar 26 17:31:13 vostro kernel: [21480.088755] [] ? task_work_run+0xb7/0xf0 Mar 26 17:31:13 vostro kernel: [21480.088758] [] ? do_notify_resume+0x69/0x90 Mar 26 17:31:13 vostro kernel: [21480.088760] [] ? int_signal+0x12/0x17 Mar 26 17:31:13 vostro kernel: [21480.088763] ---[ end trace e561afe37f492175 ]--- Anything I can do to help getting this fixed? Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- 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] [RESEND] aic7xxx: replace kmalloc/memset by kzalloc
On 03/24/2015 04:16 PM, Elliott, Robert (Server Storage) wrote:
>
> It was a reply to the original post on 2014-10-16, not the resend
> this month.
>
> From http://permalink.gmane.org/gmane.linux.kernel/1808168:
>
> kcalloc is helpful when one of the values is a variable that
> might cause the multiply to overflow during runtime. Here,
> two constants are being multiplied together, which can
> be done and checked by the compiler at compile time.
>
> Since kcalloc and kmalloc_array are both static inline
> functions:
> static inline void *kmalloc_array(size_t n, size_t size, gfp_t flags)
> {
> if (size != 0 && n > SIZE_MAX / size)
> return NULL;
> return __kmalloc(n * size, flags);
> }
> static inline void *kcalloc(size_t n, size_t size, gfp_t flags)
> {
> return kmalloc_array(n, size, flags | __GFP_ZERO);
> }
>
> a compiler that detects an overflow will probably just reduce
> that to an inlined "return NULL."
>
> BUILD_BUG_ON could be used to trigger a compile-time error,
> instead of building a kernel that returns a run-time error.
Ok, I hope we agree to get back to kzalloc() for which the compiler
won't miss size_t overflows.
Thanks for the reviews!
Michael.
--
Michael Opdenacker, CEO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
+33 484 258 098
--
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] [xfs] 834ffca6f7e: WARNING: CPU: 3 PID: 23390 at fs/xfs/xfs_file.c:700 xfs_file_dio_aio_write+0x27c/0x2e0()
On Fri, 2015-03-27 at 08:22 +1100, Dave Chinner wrote:
> On Thu, Mar 26, 2015 at 02:45:19PM +0800, Huang Ying wrote:
> > FYI, we noticed the below changes on
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > commit 834ffca6f7e345a79f6f2e2d131b0dfba8a4b67a ("xfs: don't zero partial
> > page cache pages during O_DIRECT writes")
>
> Doing what test, exactly?
Sorry, should include that information. We were running xfstests.
generic/068 generic/100 generic/117 generic/120 generic/125 generic/130
generic/192 generic/209 generic/223 generic/225 generic/226 generic/230
generic/247 generic/256 generic/275
Warning were shown during testing as above.
Best Regards,
Huang, Ying
> > [ 354.728419] XFS (vda): Unmounting Filesystem
> > [ 355.133977] XFS (vda): Mounting V4 Filesystem
> > [ 355.174239] XFS (vda): Ending clean mount
> > [ 362.820417] WARNING: CPU: 3 PID: 23390 at fs/xfs/xfs_file.c:700
> > xfs_file_dio_aio_write+0x27c/0x2e0()
> > [ 362.822109] Modules linked in: ipmi_watchdog ipmi_msghandler sg sr_mod
> > cdrom ata_generic pata_acpi cirrus syscopyarea sysfillrect sysimgblt ppdev
> > ttm ata_piix snd_pcm snd_timer drm_kms_helper libata snd microcode drm
> > soundcore pcspkr floppy serio_raw i2c_piix4 parport_pc parport acpi_cpufreq
> > [ 362.828207] CPU: 3 PID: 23390 Comm: dd Not tainted
> > 4.0.0-rc3-next-20150311 #1
> > [ 362.829908] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> > 1.7.5-20140531_083030-gandalf 04/01/2014
> > [ 362.831853] 81bb5940 88007d5c3d08 818b19e6
> > 880077f901f8
> > [ 362.833873] 88007d5c3d48 8107294a
> > ea00010cc240
> > [ 362.835646] 8800570f7400 8800570f75d0
> > 8800570f7720
> > [ 362.837330] Call Trace:
> > [ 362.838593] [] dump_stack+0x4c/0x65
> > [ 362.840023] [] warn_slowpath_common+0x8a/0xc0
> > [ 362.841652] [] warn_slowpath_null+0x1a/0x20
> > [ 362.843125] [] xfs_file_dio_aio_write+0x27c/0x2e0
> > [ 362.844694] [] xfs_file_write_iter+0x110/0x130
> > [ 362.846229] [] new_sync_write+0x81/0xb0
> > [ 362.847670] [] vfs_write+0xb7/0x1f0
> > [ 362.849152] [] ? vfs_read+0x11e/0x140
> > [ 362.850573] [] SyS_write+0x46/0xb0
> > [ 362.852055] [] system_call_fastpath+0x12/0x17
> > [ 362.853576] ---[ end trace 002c13cd5d358e1d ]---
>
> That's warning about a failure to invalidate the page cache across
> the region of a direct IO which is a potential data corruption
> event. The open(2) man page warns that applications should not do
> this
>
> Also the commit you point out as being problematic was introduced in
> 3.17-rc3 as part of a series to reduce data corruption problems when
> mixing concurrent O_DIRECT and buffered/mmap IO to the same file.
> That warning was put there on purpose to tell us that there's a
> well known reason the user is reporting data corruption
>
> Cheers,
>
> Dave.
--
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/2] spi/rockchip: Add device tree property to configure Rx Sample Delay
Julius, On Thu, Mar 26, 2015 at 4:30 PM, Julius Werner wrote: > We have found that we can sometimes see read failures on boards with > high-capacitance SPI lines. It seems that the controller samples the Rx > data line too early, and its register interface has an "Rx Sample Delay" > setting to fine-tune against this issue. > > This patch adds a new optional device tree entry that can configure this > delay in terms of nanoseconds. The kernel will calculate the > best-fitting amount of parent clock ticks to program the controller with > based on that. > > Signed-off-by: Julius Werner > --- > .../devicetree/bindings/spi/spi-rockchip.txt| 4 > drivers/spi/spi-rockchip.c | 21 > + > 2 files changed, 25 insertions(+) Reviewed-by: Doug Anderson -- 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] ASoC: Add support for NAU8824 codec to ASoC
On Thu, Mar 26, 2015 at 02:58:53PM -0700, Chih-Chiang Chang wrote: > On 3/6/2015 1:07 PM, Mark Brown wrote: > > On Fri, Mar 06, 2015 at 03:28:33PM +0800, Chih-Chiang Chang wrote: > > Please fix your mailer to word wrap within paragraphs, it makes things a > > lot easier to read. > This seems to violate the kernel's rule. I am using the Thunderbird to > do upstream. And in kernel's documentation, it shows we should set > "mailnews.wraplength" from "72" to "0". Any way, for your convenience, I > already modify the "mailnews.wraplength" back to "72". You should never word wrap code since that corrupts the patches but always word wrap text. > > I'd really like to have a better understanding of what this is doing - > > it can be valid to do this but there are some warning signs here such as > > the volume of writes being large in comparison with the set of controls > > the driver exposes which mean I'd like to be sure the use matches > > expectations. Normally this sort of thing is a small number of fixes > > for undocumented registers or updates to register defaults changed in > > later revisions of the chip. > We have tried to reduce the sequence recently, but it got some issues in > the tests. We think these large number of register settings are > necessary to our NAU8824 codec. We will provide the comments of all > values in source to have a better understanding, is it acceptable to you? It sounds reasonable but obviously I've not seen the results yet. signature.asc Description: Digital signature
Re: [PATCH 1/2] spi/rockchip: Round up clock rate divisor to err on the safe side
Julius, On Thu, Mar 26, 2015 at 4:30 PM, Julius Werner wrote: > The Rockchip SPI driver currently calculates its clock rate divisor by > integer dividing the parent rate by the target rate, and then rounding > the result up to the next even number (since the divisor must be > even). > > Clock rate divisors should always be rounded up, so that the resulting > frequency is lower or equal to the target. This is correctly done in the > second step here but not in the first, so we still have a risk of > exceeding the desired target frequency (e.g. setting spi-max-frequency > to 4000 with a parent clock of 9900 could lead to a divisor of > 9900 / 4000 == 2 (which is even) that then results in an > effective frequency of 9900 / 2 == 4950 (potentially exceeding > the flash chip's specifications). > > This patch changes the division to round up to fix this problem. > > Signed-off-by: Julius Werner > --- > drivers/spi/spi-rockchip.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Doug Anderson -- 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/
linux-next: build failure after merge of the arm64 tree
Hi Catalin, Yesterday's linux-next overnight builds (most arm builds) failed like this: ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size' referenced in expression See, for example, http://kisskb.ellerman.id.au/kisskb/buildresult/12391163/ . Have a look at http://kisskb.ellerman.id.au/kisskb/head/8631/ to see the full carnage :-( This has been happening for a couple of days and then before that we got: /opt/cross/gcc-4.6.3-nolibc/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-ld:./arch/arm/kernel/vmlinux.lds:544: syntax error We are using gcc 4.6.3 and binutils 2.22 to do these builds. I have reverted 12eb3e833961ARM: kvm: assert on HYP section boundaries not actual code size e60a1fec44a2ARM: kvm: implement replacement for ld's LOG2CEIL() 06f75a1f6200ARM, arm64: kvm: get rid of the bounce page from linux-next today. Please address this ASAP. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpcaBoJ9pFRF.pgp Description: OpenPGP digital signature
Re: [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap
On Thu, 2015-03-26 at 10:43 +0100, Ingo Molnar wrote:
> * Benjamin Herrenschmidt wrote:
>
> > On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote:
> > > * Ingo Molnar wrote:
> > >
> > > > > +#define __HAVE_ARCH_REMAP
> > > > > +static inline void arch_remap(struct mm_struct *mm,
> > > > > + unsigned long old_start, unsigned long
> > > > > old_end,
> > > > > + unsigned long new_start, unsigned long
> > > > > new_end)
> > > > > +{
> > > > > + /*
> > > > > + * mremap() doesn't allow moving multiple vmas so we can limit
> > > > > the
> > > > > + * check to old_start == vdso_base.
> > > > > + */
> > > > > + if (old_start == mm->context.vdso_base)
> > > > > + mm->context.vdso_base = new_start;
> > > > > +}
> > > >
> > > > mremap() doesn't allow moving multiple vmas, but it allows the
> > > > movement of multi-page vmas and it also allows partial mremap()s,
> > > > where it will split up a vma.
> > >
> > > I.e. mremap() supports the shrinking (and growing) of vmas. In that
> > > case mremap() will unmap the end of the vma and will shrink the
> > > remaining vDSO vma.
> > >
> > > Doesn't that result in a non-working vDSO that should zero out
> > > vdso_base?
> >
> > Right. Now we can't completely prevent the user from shooting itself
> > in the foot I suppose, though there is a legit usage scenario which
> > is to move the vDSO around which it would be nice to support. I
> > think it's reasonable to put the onus on the user here to do the
> > right thing.
>
> I argue we should use the right condition to clear vdso_base: if the
> vDSO gets at least partially unmapped. Otherwise there's little point
> in the whole patch: either correctly track whether the vDSO is OK, or
> don't ...
Well, if we are going to clear it at all yes, we should probably be a
bit smarter about it. My point however was we probably don't need to be
super robust about dealing with any crazy scenario userspace might
conceive.
> There's also the question of mprotect(): can users mprotect() the vDSO
> on PowerPC?
Nothing prevents it. But here too, I wouldn't bother. The user might be
doing on purpose expecting to catch the resulting signal for example
(though arguably a signal from a sigreturn frame is ... odd).
Cheers,
Ben.
--
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/
