linux-next: manual merge of the mvebu tree with the arm-soc tree
Hi all, Today's linux-next merge of the mvebu tree got conflicts in various files between merges and commits in the arm-soc tree and merges in the mvebu tree. These merges/commits in the mvebu tree appear to be from a previous version of the arm-soc tree that the mvebu tree has been rebased upon. Please don't do that - the arm-soc tree as a whole is not stable. I fixed it up (I used the version from the current arm-soc tree) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpn9y3kjWb_0.pgp Description: PGP signature
Re: [PATCH v6 0/5] zram/zsmalloc promotion
Hi Luigi, On 08/19/2013 01:29 PM, Luigi Semenzato wrote: We are gearing up to evaluate zswap, but we have only ported kernels up to 3.8 to our hardware, so we may be missing important patches. In our experience, and with all due respect, the linux MM is a complex beast, and it's difficult to predict how hard it will be for us to switch to zswap. Even with the relatively simple zram, our load I think it will be easy if zswap can also create a pseudo block device(I already done the simple implementation [PATCH 0/4] mm: merge zram into zswap), then it's transparent for original zram users. triggered bugs in other parts of the MM that took a fair amount of work to resolve. I may be wrong, but the in-memory compressed block device implemented by zram seems like a simple device which uses a well-established API to the rest of the kernel. If it is removed from the kernel, will it be difficult for us to carry our own patch? Because we may have to do that for a while. Of course we would prefer it if it stayed in, at least temporarily. Also, could someone confirm or deny that the maximum compression ratio in zbud is 2? Because we easily achieve a 2.6-2.8 compression ratio with our loads using zram with zsmalloc and LZO or snappy. Losing that memory will cause a noticeable regression, which will encourage us to stick with zram. I am hoping that our load is not so unusual that we are the only Linux users in this situation, and that zsmalloc (or other allocator-compressor with similar characteristics) will continue to exist, whether it is used by zram or zswap. Thanks! -- Regards, -Bob -- 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] tile: support kprobes on tilegx
(2013/08/13 23:08), Tony Lu wrote:
This change includes support for Kprobes, Jprobes and Return Probes.
This looks OK for me, just reviewed, not tested :).
Reviewed-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Thank you!
Signed-off-by: Tony Lu z...@tilera.com
Signed-off-by: Chris Metcalf cmetc...@tilera.com
---
v2: implement Masami Hiramatsu's suggestion to add an insn_has_control()
check to disallow placing probes on instructions that modify control flow.
We can improve this in a later change if it seems useful.
arch/tile/Kconfig| 2 +
arch/tile/include/asm/Kbuild | 1 -
arch/tile/include/asm/kdebug.h | 28 ++
arch/tile/include/asm/kprobes.h | 79
arch/tile/include/asm/ptrace.h | 1 +
arch/tile/include/uapi/arch/opcode_tilegx.h | 1 +
arch/tile/include/uapi/arch/opcode_tilepro.h | 1 +
arch/tile/kernel/Makefile| 1 +
arch/tile/kernel/kprobes.c | 528
+++
arch/tile/kernel/smp.c | 14 +-
arch/tile/kernel/traps.c | 42 +++
arch/tile/kernel/vmlinux.lds.S | 1 +
arch/tile/mm/fault.c | 12 +
samples/kprobes/kprobe_example.c | 9 +
14 files changed, 716 insertions(+), 4 deletions(-)
create mode 100644 arch/tile/include/asm/kdebug.h
create mode 100644 arch/tile/include/asm/kprobes.h
create mode 100644 arch/tile/kernel/kprobes.c
diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig
index e1600be..ecff467 100644
--- a/arch/tile/Kconfig
+++ b/arch/tile/Kconfig
@@ -125,6 +125,8 @@ config TILEGX
select HAVE_FUNCTION_GRAPH_TRACER
select HAVE_DYNAMIC_FTRACE
select HAVE_FTRACE_MCOUNT_RECORD
+ select HAVE_KPROBES
+ select HAVE_KRETPROBES
config TILEPRO
def_bool !TILEGX
diff --git a/arch/tile/include/asm/Kbuild b/arch/tile/include/asm/Kbuild
index b17b9b8..4c0b3c2 100644
--- a/arch/tile/include/asm/Kbuild
+++ b/arch/tile/include/asm/Kbuild
@@ -15,7 +15,6 @@ generic-y += ioctl.h
generic-y += ioctls.h
generic-y += ipcbuf.h
generic-y += irq_regs.h
-generic-y += kdebug.h
generic-y += local.h
generic-y += msgbuf.h
generic-y += mutex.h
diff --git a/arch/tile/include/asm/kdebug.h b/arch/tile/include/asm/kdebug.h
new file mode 100644
index 000..5bbbfa9
--- /dev/null
+++ b/arch/tile/include/asm/kdebug.h
@@ -0,0 +1,28 @@
+/*
+ * Copyright 2012 Tilera Corporation. All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation, version 2.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
+ * NON INFRINGEMENT. See the GNU General Public License for
+ * more details.
+ */
+
+#ifndef _ASM_TILE_KDEBUG_H
+#define _ASM_TILE_KDEBUG_H
+
+#include linux/notifier.h
+
+enum die_val {
+ DIE_OOPS = 1,
+ DIE_BREAK,
+ DIE_SSTEPBP,
+ DIE_PAGE_FAULT,
+ DIE_COMPILED_BPT
+};
+
+#endif /* _ASM_TILE_KDEBUG_H */
diff --git a/arch/tile/include/asm/kprobes.h b/arch/tile/include/asm/kprobes.h
new file mode 100644
index 000..d8f9a83
--- /dev/null
+++ b/arch/tile/include/asm/kprobes.h
@@ -0,0 +1,79 @@
+/*
+ * arch/tile/include/asm/kprobes.h
+ *
+ * Copyright 2012 Tilera Corporation. All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation, version 2.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
+ * NON INFRINGEMENT. See the GNU General Public License for
+ * more details.
+ */
+
+#ifndef _ASM_TILE_KPROBES_H
+#define _ASM_TILE_KPROBES_H
+
+#include linux/types.h
+#include linux/ptrace.h
+#include linux/percpu.h
+
+#include arch/opcode.h
+
+#define __ARCH_WANT_KPROBES_INSN_SLOT
+#define MAX_INSN_SIZE2
+
+#define kretprobe_blacklist_size 0
+
+typedef tile_bundle_bits kprobe_opcode_t;
+
+#define flush_insn_slot(p) \
+ flush_icache_range((unsigned long)p-addr, \
+(unsigned long)p-addr + \
+(MAX_INSN_SIZE * sizeof(kprobe_opcode_t)))
+
+struct kprobe;
+
+/* Architecture specific copy of original instruction. */
+struct arch_specific_insn {
+ kprobe_opcode_t *insn;
+};
+
+struct prev_kprobe {
Re: [PATCH] acpi_i2c: set MODULE_LICENSE, MODULE_AUTHOR, and MODULE_DESCRIPTION
On Fri, Aug 16, 2013 at 06:26:35PM -0700, Jerry Snitselaar wrote: Without MODULE_LICENSE set, I get the following with modprobe: acpi_i2c: module license 'unspecified' taints kernel. acpi_i2c: Unknown symbol i2c_new_device (err 0) acpi_i2c: Unknown symbol acpi_dev_get_resources (err 0) acpi_i2c: Unknown symbol acpi_dev_resource_interrupt (err 0) acpi_i2c: Unknown symbol acpi_dev_free_resource_list (err 0) Signed-off-by: Jerry Snitselaar jerry.snitsel...@oracle.com Looks good to me. Acked-by: Mika Westerbeg mika.westerb...@linux.intel.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 v6 0/5] zram/zsmalloc promotion
Hello Luigi,
On Sun, Aug 18, 2013 at 10:29:18PM -0700, Luigi Semenzato wrote:
On Sun, Aug 18, 2013 at 9:37 PM, Minchan Kim minc...@kernel.org wrote:
Hello Bob,
Sorry for the late response. I was on holiday.
On Mon, Aug 19, 2013 at 11:57:41AM +0800, Bob Liu wrote:
Hi Minchan,
On 08/19/2013 11:18 AM, Minchan Kim wrote:
Hello Mel,
On Fri, Aug 16, 2013 at 09:33:47AM +0100, Mel Gorman wrote:
On Fri, Aug 16, 2013 at 01:26:41PM +0900, Minchan Kim wrote:
SNIP
If it's used for something like tmpfs then it becomes much worse.
Normal
tmpfs without swap can lockup if tmpfs is allowed to fill memory.
In a
sane configuration, lockups will be avoided and deleting a tmpfs
file is
guaranteed to free memory. When zram is used to back tmpfs, there
is no
guarantee that any memory is freed due to fragmentation of the
compressed
pages. The only way to recover the memory may be to kill
applications
holding tmpfs files open and then delete them which is fairly
drastic
action in a normal server environment.
Indeed.
Actually, I had a plan to support zsmalloc compaction. The zsmalloc
exposes
handle instead of pure pointer so it could migrate some zpages to
somewhere
to pack in. Then, it could help above problem and OOM storm problem.
Anyway, it's a totally new feature and requires many changes and
experiement.
Although we don't have such feature, zram is still good for many
people.
And is zsmalloc was pluggable for zswap then it would also benefit.
But zswap isn't pseudo block device so it couldn't be used for block
device.
It would not be impossible to write one. Taking a quick look it might
even
be doable by just providing a zbud_ops that does not have an evict
handler
and make sure the errors are handled correctly. i.e. does the following
patch mean that zswap never writes back and instead just compresses
pages
in memory?
diff --git a/mm/zswap.c b/mm/zswap.c
index deda2b6..99e41c8 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -819,7 +819,6 @@ static void
zswap_frontswap_invalidate_area(unsigned type)
}
static struct zbud_ops zswap_zbud_ops = {
- .evict = zswap_writeback_entry
};
static void zswap_frontswap_init(unsigned type)
If so, it should be doable to link that up in a sane way so it can be
configured at runtime.
Did you ever even try something like this?
Never. Because I didn't have such requirement for zram.
Let say one usecase for using zram-blk.
1) Many embedded system don't have swap so although tmpfs can support
swapout
it's pointless still so such systems should have sane configuration to
limit
memory space so it's not only zram problem.
If zswap was backed by a pseudo device that failed all writes or an an
ops with no evict handler then it would be functionally similar.
2) Many embedded system don't have enough memory. Let's assume
short-lived
file growing up until half of system memory once in a while. We don't
want
to write it on flash by wear-leveing issue and very slowness so we
want to use
in-memory but if we uses tmpfs, it should evict half of working set to
cover
them when the size reach peak. zram would be better choice.
Then back it by a pseudo device that fails all writes so it does not
have
to write to disk.
You mean make pseudo block device and register make_request_fn
and prevent writeback. Bah, yes, it's doable but what is it different
with below?
1) move zbud into zram
2) implement frontswap API in zram
3) implement writebazk in zram
The zram has been for a long time in staging to be promoted and have been
maintained/deployed. Of course, I have asked the promotion several times
for above a year.
Why can't zram include zswap functions if you really want to merge them?
Is there any problem?
I think merging zram into zswap or merging zswap into zram are the same
thing. It's no difference.
True but i'd like to merge zswap code into zram.
Because as you know, zram has already lots of users while zswap is almost
new young so I'd like to keep backward compatibility for zram so moving
zswap code
into zram is more handy and could keep the git log as well.
Both way will result in a solution finally with zram block device,
frontswap API etc.
Right but z* family people should discuss that zswap-writeback is really
good solution for compressed swap. Firstly, I thought zswap is differnt with
zram so there is no issue to promote zram so I and Nitin helped zsmalloc
promotion for Seth and have reviewed at zswap inital phases but the
situation
is chainging. Let's discussion further points about compresssed swap
solution.
I raised issues as reply of Mel in my thread. Let's think of it.
The difference is
Re: [PATCH v2 0/2] omap4/twl6030: typical connection to omap4 as a separate dtsi file
Hi Benoit, On Fri, Aug 16, 2013 at 4:20 PM, Benoit Cousson bcous...@baylibre.com wrote: Hi Ruslan, On 16/08/2013 14:04, Ruslan Bilovol wrote: Hi Benoit, On Wed, Aug 14, 2013 at 4:51 PM, Benoit Cousson bcous...@baylibre.com wrote: Hi Ruslan, On 14/08/2013 10:35, Ruslan Bilovol wrote: Hello, There is no functional changes between v1 and v2 - just added the patch for omap4-var-som - Uri Yosef confirmed this board have the same connection of OMAP4-TWL6030 as SDP4430 board The series looks good to me, but it will be good to have a test for Panda and Variscite boards before merging it. Okay, so I just verified this patch series on PandaBoard ES2. Should I resubmit this series with fixed commit message? No, that's fine, I already applied it and fixed the subject and the changelog. Here it is: commit 2e25df1e5a4af906a9b25332719ace63eb0d Author: Ruslan Bilovol ruslan.bilo...@ti.com Date: Wed Aug 14 11:35:47 2013 +0300 ARM: dts: twl6030: Move common configuration for OMAP4 boards in a separate dtsi file The OMAP4 SoC family uses specially-designed PMIC (power management IC) companion chip for power management needs: TWL6030/TWL6032. Therefore there is a typical connection of PMIC to OMAP4 so we can move it into separate .dtsi file and do not duplicate over board-specific files. Tested on OMAP4 SDP board and compile-tested for Panda board Just for archives: I've successfully tested it on PandaBoard ES2 last week as well. Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com Signed-off-by: Benoit Cousson bcous...@baylibre.com Just let me know if you are OK with the updated version. Yes, this version looks good to me. Thanks for picking it up! However I cannot verify the patch for Variscite board because I do not own any such board so you can drop that patch. But maybe Uri Yosef can verify it. Uri? It seems that Uri cannot test it right now, so I will have to drop that one. Okay, let's wait for Uri's verification. Best regards, Ruslan Thanks, Benoit -- 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: [Xen-devel] [PATCH] xen: initialize xen panic handler for PVHVM
On 08/16/13 20:43, Konrad Rzeszutek Wilk wrote: Could you tell me what has been happening without this patch? Without this patch, Xen would not get pvhvm crash event, any config for on_crash in guest configure file will not be triggered. Thanks, Joe -- 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: musb: Avoid null pointer dereference in debug logging
Since commit 511f3c53 (usb: gadget: udc-core: fix a regression during gadget driver unbinding) usb_gadget_remove_driver will pass NULL for the driver argument. Signed-off-by: Maarten ter Huurne maar...@treewalker.org --- drivers/usb/musb/musb_gadget.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c index ba70923..82e5386 100644 --- a/drivers/usb/musb/musb_gadget.c +++ b/drivers/usb/musb/musb_gadget.c @@ -1935,7 +1935,8 @@ static int musb_gadget_stop(struct usb_gadget *g, stop_activity(musb, driver); otg_set_peripheral(musb-xceiv-otg, NULL); - dev_dbg(musb-controller, unregistering driver %s\n, driver-function); + dev_dbg(musb-controller, unregistering driver %s\n, + driver ? driver-function : (removed)); musb-is_active = 0; musb-gadget_driver = NULL; -- 1.8.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: [PATCH 1/2] i2c-designware: make *CNT values configurable
Sorry for the slooow response, I've been on vacation. On Tue, Jul 16, 2013 at 01:16:18PM +0200, Christian Ruppert wrote: Second step is that if current i2c_dw_scl_hcnt and i2c_dw_scl_lcnt calculations don't suit with later DW I2C cores, then it would be nice for someone who can access to the data book to update formulas, or provide alternative formulas and make them selectable depending on DW core versions. I'm not having the impression there is a huge difference between the different generations of DW blocks. Probably we can find one formula that suits all blocks. We just have to be careful (in doubt rather conservative) with the transition times. This seems to be currently the case and if I understand Mika correctly, his objective is to remove some of this conservatism. What I had originally in mind was that we could just pass whatever HCNT/LCNT values we get from system FW (with the help of ACPI or DT). However, if we can make the HCNT/LCNT calculation more accurate using tf and tr, that are passed from DT or platform data, we should implement that as well (as a separate patch). It always helps us to have a way to calculate *HCNT and *LCNT values automatically. As said above, DW I2C core can control tHIGH, tLOW, tHD;STA, etc. quite _accurate_, if HCNT/LCNT values were calculated with proper formulas. It also helps hardware people as well to provide reference HCNT/LCNT values. And as a third step, if we want to use optimized HCNT/LCNT values which can not be obtained from proper formulas + user-requested tf/tr, or if we want to use HCNT/LCNT settings verified by vendors or provided from hardware team, then I'm fine with having a way to _override_ HCNT/LCNT values. Such direct way might be useful. I agree. Probably it is best to have both, a default method based on formulas and timing parameters (the formulas are quite simple anyway) which works with device tree and such and a second method based on register values which works with mechanisms like ACPI. I agree. I'm going to post a new version of this patch (and the SDA hold patch) that takes care of the ACPI case if there are no objections. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] ARM: tegra: configure power off for Dalmore
Add DT property to tell the regulator to register pm_power_off to make
shutdown work.
Signed-off-by: Bill Huang bilhu...@nvidia.com
---
arch/arm/boot/dts/tegra114-dalmore.dts |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts
b/arch/arm/boot/dts/tegra114-dalmore.dts
index 45056a2..6023028 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -845,6 +845,8 @@
#interrupt-cells = 2;
interrupt-controller;
+ ti,system-power-controller;
+
palmas_gpio: gpio {
compatible = ti,palmas-gpio;
gpio-controller;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/7] cpufreq:boost: CPU Boost mode support
On 13 August 2013 15:38, Lukasz Majewski l.majew...@samsung.com wrote: This patch series introduces support for CPU overclocking technique called Boost. It is a follow up of a LAB governor proposal. Boost is a LAB component: http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq Boost unifies hardware based solution (e.g. Intel Nehalem) with software oriented one (like the one done at Exynos). For this reason cpufreq/freq_table code has been reorganized to include common code. Important design decisions: - Boost related code is compiled-in unconditionally to cpufreq core and disabled by default. The cpufreq_driver is responsibile for setting boost_supported flag and providing set_boost callback(if HW support is needed). For software managed boost, special Kconfig flag - CONFIG_CPU_FREQ_BOOST_SW has been defined. It will be selected only when a target platform has thermal framework properly configured. - struct cpufreq_driver has been extended with boost related fields: -- boost_supported - when driver supports boosting -- boost_enabled - boost state -- set_boost - callback to function, which is necessary to enable/disable boost - Boost sysfs attribute (/sys/devices/system/cpu/cpufreq/boost) is visible _only_ when cpufreq driver supports Boost. - No special spin_lock for Boost was created. The one from cpufreq core was reused. - The Boost code doesn't rely on any policy. When boost state is changed, then the policy list is iterated and proper adjustements are done. - To improve safety level, the thermal framework is also extended to disable software boosting, when thermal trip point is reached. Then it starts monitoring target temperature to evaluate if boost can be enabled again. This emulates behaviour similar to HW managed boost (like x86) Tested at HW: Exynos 4412 3.11-rc4 Linux Intel Core i7-3770 3.11-rc4 Linux Above patches were posted on top of linux_pm/linux-next with following patches applied: cpufreq: exynos5440: Fix to skip when new frequency same as current cpufreq: fix EXYNOS drivers selection Lukasz Majewski (7): cpufreq: Add boost frequency support in core cpufreq:acpi:x86: Adjust the acpi-cpufreq.c code to work with common boost solution thermal:boost: Automatic enable/disable of BOOST feature cpufreq:boost:Kconfig: Provide support for software managed BOOST cpufreq:exynos:Extend Exynos cpufreq driver to support boost framework Documentation:cpufreq:boost: Update BOOST documentation cpufreq:exynos4x12: Change L0 driver data to CPUFREQ_BOOST_FREQ Hi Lukasz, I haven't found time yet to go through this series.. I want to do a deep/careful review this time as these are almost the final patches. Will try to get over them by the end of this week.. -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] UBI: Fix PEB leak in wear_leveling_worker()
get_peb_for_wl() removes the PEB from the free list.
If the WL subsystem detects that no wear leveling is needed
it cancels the operation and drops the gained PEB.
In this case we have to put the PEB back into the free list.
This issue was introduced with commit ed4b7021c
(UBI: remove PEB from free tree in get_peb_for_wl()).
Cc: sta...@vger.kernel.org # 3.7.x
Signed-off-by: Richard Weinberger rich...@nod.at
---
drivers/mtd/ubi/wl.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mtd/ubi/wl.c b/drivers/mtd/ubi/wl.c
index 5df49d3..c95bfb1 100644
--- a/drivers/mtd/ubi/wl.c
+++ b/drivers/mtd/ubi/wl.c
@@ -1069,6 +1069,9 @@ static int wear_leveling_worker(struct ubi_device *ubi,
struct ubi_work *wrk,
if (!(e2-ec - e1-ec = UBI_WL_THRESHOLD)) {
dbg_wl(no WL needed: min used EC %d, max free EC %d,
e1-ec, e2-ec);
+
+ /* Give the unused PEB back */
+ wl_tree_add(e2, ubi-free);
goto out_cancel;
}
self_check_in_wl_tree(ubi, e1, ubi-used);
--
1.8.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: [PATCH] dma: cpp41: make it compile with CONFIG_BUG=n
On Fri, Aug 16, 2013 at 05:40:55PM +0200, Sebastian Andrzej Siewior wrote:
From: Sebastian Andrzej Siewior bige...@linutronix.de
Before Randy figures out that this does not compile with CONFIG_BUG=n
here is a fix for it.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
Acked-by: Vinod Koul vinod.k...@intel.com
~Vinod
---
drivers/dma/cppi41.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index 5dcebca..e696178 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -579,7 +579,7 @@ static int cppi41_tear_down_chan(struct cppi41_channel *c)
WARN_ON(!c-is_tx !(pd0 TD_DESC_IS_RX));
WARN_ON((pd0 0x1f) != c-port_num);
} else {
- __WARN();
+ WARN_ON_ONCE(1);
}
c-td_seen = 1;
}
--
1.8.4.rc2
--
--
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/7] cpufreq:boost: CPU Boost mode support
On Mon, 19 Aug 2013 12:08:26 +0530 Viresh Kumar viresh.ku...@linaro.org wrote, On 13 August 2013 15:38, Lukasz Majewski l.majew...@samsung.com wrote: This patch series introduces support for CPU overclocking technique called Boost. It is a follow up of a LAB governor proposal. Boost is a LAB component: http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq Boost unifies hardware based solution (e.g. Intel Nehalem) with software oriented one (like the one done at Exynos). For this reason cpufreq/freq_table code has been reorganized to include common code. Important design decisions: - Boost related code is compiled-in unconditionally to cpufreq core and disabled by default. The cpufreq_driver is responsibile for setting boost_supported flag and providing set_boost callback(if HW support is needed). For software managed boost, special Kconfig flag - CONFIG_CPU_FREQ_BOOST_SW has been defined. It will be selected only when a target platform has thermal framework properly configured. - struct cpufreq_driver has been extended with boost related fields: -- boost_supported - when driver supports boosting -- boost_enabled - boost state -- set_boost - callback to function, which is necessary to enable/disable boost - Boost sysfs attribute (/sys/devices/system/cpu/cpufreq/boost) is visible _only_ when cpufreq driver supports Boost. - No special spin_lock for Boost was created. The one from cpufreq core was reused. - The Boost code doesn't rely on any policy. When boost state is changed, then the policy list is iterated and proper adjustements are done. - To improve safety level, the thermal framework is also extended to disable software boosting, when thermal trip point is reached. Then it starts monitoring target temperature to evaluate if boost can be enabled again. This emulates behaviour similar to HW managed boost (like x86) Tested at HW: Exynos 4412 3.11-rc4 Linux Intel Core i7-3770 3.11-rc4 Linux Above patches were posted on top of linux_pm/linux-next with following patches applied: cpufreq: exynos5440: Fix to skip when new frequency same as current cpufreq: fix EXYNOS drivers selection Lukasz Majewski (7): cpufreq: Add boost frequency support in core cpufreq:acpi:x86: Adjust the acpi-cpufreq.c code to work with common boost solution thermal:boost: Automatic enable/disable of BOOST feature cpufreq:boost:Kconfig: Provide support for software managed BOOST cpufreq:exynos:Extend Exynos cpufreq driver to support boost framework Documentation:cpufreq:boost: Update BOOST documentation cpufreq:exynos4x12: Change L0 driver data to CPUFREQ_BOOST_FREQ Hi Lukasz, Hi Viresh, I haven't found time yet to go through this series.. I've just started wondering if I had send those patches correctly :-). I want to do a deep/careful review this time as these are almost the final patches. Ok. Will try to get over them by the end of this week.. Ok, I understand. -- viresh -- 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 -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group -- 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: Seq File: Return error if d_path fails
Hi Andrew, On Tue, Aug 13, 2013 at 3:19 AM, Andrew Morton a...@linux-foundation.org wrote: On Thu, 8 Aug 2013 19:03:31 +0530 Arun KS arunks.li...@gmail.com wrote: From 2558382c8a030f7261e47977ac62412cd78e6d38 Mon Sep 17 00:00:00 2001 From: Arun KS arun...@broadcom.com Date: Thu, 8 Aug 2013 18:23:04 +0530 Subject: Seq File: Return error if d_path fails Return error if d_path fails in seq_path funciton. If we do not return from here, seq_commit sets seq_file state as overflow. And this continues in a loop utill we increase the size of seq buf beyond KMALLOC_MAX_SIZE. ... --- a/fs/seq_file.c +++ b/fs/seq_file.c @@ -471,7 +471,8 @@ int seq_path(struct seq_file *m, const struct path *path, const char *esc) char *end = mangle_path(buf, p, esc); if (end) res = end - buf; - } + } else + return PTR_ERR(p); } seq_commit(m, res); hm, does that really fix the bug? Isn't the core problem the word or: /** * seq_commit - commit data to the buffer * @m: the seq_file handle * @num: the number of bytes to commit * * Commit @num bytes of data written to a buffer previously acquired * by seq_buf_get. To signal an error condition, or that the data ^^ * didn't fit in the available space, pass a negative @num value. */ seq_path()/seq_commit() is treating a d_path() failure as an overflow condition, but it isn't. I ll send a new patch. Thanks, Arun -- 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] SeqFile: Fix overflow condition
From 23986a85b9efe7bc3ffc0887b8d17cdf2fbab4f2 Mon Sep 17 00:00:00 2001
From: Arun KS arun...@broadcom.com
Date: Mon, 19 Aug 2013 12:06:33 +0530
Subject: SeqFile: Fix overflow condition
seq_path()/seq_commit() is treating a d_path() failure as an overflow
condition, but it isn't.
Signed-off-by: Arun KS arun...@broadcom.com
---
fs/seq_file.c| 6 +++---
include/linux/seq_file.h | 11 ++-
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/fs/seq_file.c b/fs/seq_file.c
index 3135c25..6a33f9c 100644
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -463,7 +463,7 @@ int seq_path(struct seq_file *m, const struct path
*path, const char *esc)
{
char *buf;
size_t size = seq_get_buf(m, buf);
- int res = -1;
+ int res = -ENOBUFS;
if (size) {
char *p = d_path(path, buf, size);
@@ -487,7 +487,7 @@ int seq_path_root(struct seq_file *m, const struct
path *path,
{
char *buf;
size_t size = seq_get_buf(m, buf);
- int res = -ENAMETOOLONG;
+ int res = -ENOBUFS;
if (size) {
char *p;
@@ -516,7 +516,7 @@ int seq_dentry(struct seq_file *m, struct dentry
*dentry, const char *esc)
{
char *buf;
size_t size = seq_get_buf(m, buf);
- int res = -1;
+ int res = -ENOBUFS;
if (size) {
char *p = dentry_path(dentry, buf, size);
diff --git a/include/linux/seq_file.h b/include/linux/seq_file.h
index 4e32edc..7bfb540 100644
--- a/include/linux/seq_file.h
+++ b/include/linux/seq_file.h
@@ -66,16 +66,17 @@ static inline size_t seq_get_buf(struct seq_file
*m, char **bufp)
* @num: the number of bytes to commit
*
* Commit @num bytes of data written to a buffer previously acquired
- * by seq_buf_get. To signal an error condition, or that the data
- * didn't fit in the available space, pass a negative @num value.
+ * by seq_buf_get. To signal an overflow condition(data didn't fit
+ * in the available space), pass -ENOBUFS and for other errors pass a
+ * negative @num value.
*/
static inline void seq_commit(struct seq_file *m, int num)
{
- if (num 0) {
- m-count = m-size;
- } else {
+ if (num = 0) {
BUG_ON(m-count + num m-size);
m-count += num;
+ } else if (num == -ENOBUFS)
+ m-count = m-size;
}
}
--
1.8.2
0001-SeqFile-Fix-overflow-condition.patch
Description: Binary data
Re: Re: [PATCH] Staging: rtl8192e: rtllib_rx: checking NULL value afterdoing dev_alloc_skb
On Mon, Aug 19, 2013 at 09:15:15AM +0800, rucsoftsec wrote: I have read that file. But the trouble is that I was not sure whether it is a bug or not. So I report it to BugZilla, and wait for further confirmation. Thank you all the same! If you send it to kernel-janitors we will be happy to review it. It will be faster than bugzilla. regards, dan carpenter -- 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: build warning after merge of the tip tree
* Stephen Rothwell s...@canb.auug.org.au wrote: Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) produced this warning: arch/x86/kernel/paravirt.c:66:0: warning: DEF_NATIVE redefined [enabled by default] #define DEF_NATIVE(ops, name, code) \ ^ In file included from arch/x86/include/asm/ptrace.h:65:0, from arch/x86/include/asm/alternative.h:8, from arch/x86/include/asm/bitops.h:16, from include/linux/bitops.h:22, from include/linux/kernel.h:10, from include/linux/cache.h:4, from include/linux/time.h:4, from include/linux/stat.h:18, from include/linux/module.h:10, from arch/x86/kernel/paravirt.c:22: arch/x86/include/asm/paravirt_types.h:391:0: note: this is the location of the previous definition #define DEF_NATIVE(ops, name, code) \ ^ Introduced by commit 9a55fdbe941e (x86, asmlinkage, paravirt: Add __visible/asmlinkage to xen paravirt ops). The 2 definitions used to be identical ... maybe there should be only one. Andi, please send a fix for this build warning, against tip:x86/asmlinkage. Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] nouveau: fix reclocking on nv40
On Friday 16 August 2013 14:57:07 Pali Rohár wrote: In commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was introduced error which cause that reclocking on nv40 not working anymore. There is missing assigment of return value from pll_calc to ret. Signed-off-by: Pali Rohár pali.ro...@gmail.com Signed-off-by: Martin Peres martin.pe...@labri.fr --- drivers/gpu/drm/nouveau/nv40_pm.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c b/drivers/gpu/drm/nouveau/nv40_pm.c index 3af5bcd..625f80d 100644 --- a/drivers/gpu/drm/nouveau/nv40_pm.c +++ b/drivers/gpu/drm/nouveau/nv40_pm.c @@ -131,7 +131,7 @@ nv40_calc_pll(struct drm_device *dev, u32 reg, struct nvbios_pll *pll, if (clk pll-vco1.max_freq) pll-vco2.max_freq = 0; - pclk-pll_calc(pclk, pll, clk, coef); + ret = pclk-pll_calc(pclk, pll, clk, coef); if (ret == 0) return -ERANGE; Hello, it is possible to include this patch in 3.11? Or it is too late now and need to wait for 3.12? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: High load which eventually leads to lockup
-Greg KH gre...@linuxfoundation.org wrote: - On Sun, Aug 18, 2013 at 04:32:23PM +0200, Joakim Tjernlund wrote: The last week I have had 4 lockups which required power on/off. Before getting there I noticed that the machine was getting slow.top reported high load(5-10) but there was no process consuming CPU except for migration/0 which were spicing 100% on and off. Ping times went up with a factor of 40 too.Eventually I got a few entries in the kernel log: Aug 16 12:40:51 gentoo-jocke kernel: Modules linked in: nfnetlink_log nfnetlink bluetooth rfkill sg isofs ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp ip6table_filter ip6_tables iptable_filter ip_tables ebtables x_tables autofs4 nfsd dm_crypt vboxnetadp(O) vboxnetflt(O) vboxdrv(O) usbhid dm_mod kvm_intel kvm snd_hda_codec_hdmi aesni_intel ablk_helper cryptd xts lrw gf128mul snd_hda_codec_realtek ehci_pci ehci_hcd usbcore snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_timer snd microcode usb_common radeon e1000e ttm firmware_class ptp pps_core pcspkr Aug 16 12:40:51 gentoo-jocke kernel: CPU 0 Aug 16 12:40:51 gentoo-jocke kernel: Pid: 2421, comm: X Tainted: G O 3.9.11 #1 Hewlett-Packard HP Compaq 8200 Elite CMT PC/1494 The virtual box drivers are a huge mess. Seriously, I really don't even know how the things are able to work at all (virtual table pointers from userspace through to the kernel?) I spent a bunch of time to try to clean them up and get them into mergable state, but without the ability to also fix up the userspace side, that ended up being a dead-end. Can you duplicate the problem without these modules loaded? I'd blame them for any problems you might ever have, given how crazy they are. thanks, greg k-h ok you don't trust them even if I haven't used VirtualBox between failures? Anyhow, I will unload them, lets hope for the best :) Jocke -- 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 akpm-current tree with the ext4 tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
fs/ext4/inode.c between commit 4958dee0e70f (ext4: simplify truncation
code in ext4_setattr()) from the ext4 tree and commit fb6854ec9753
(truncate: drop 'oldsize' truncate_pagecache() parameter) from the
akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc fs/ext4/inode.c
index fc4051e,9257d79..000
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@@ -4598,9 -4523,7 +4598,8 @@@ int ext4_setattr(struct dentry *dentry
ext4_journal_stop(handle);
}
- if (attr-ia_valid ATTR_SIZE) {
+ if (attr-ia_valid ATTR_SIZE attr-ia_size != inode-i_size) {
+ handle_t *handle;
- loff_t oldsize = inode-i_size;
if (!(ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS))) {
struct ext4_sb_info *sbi = EXT4_SB(inode-i_sb);
@@@ -4608,69 -4531,71 +4607,69 @@@
if (attr-ia_size sbi-s_bitmap_maxbytes)
return -EFBIG;
}
- }
-
- if (S_ISREG(inode-i_mode)
- attr-ia_valid ATTR_SIZE
- (attr-ia_size inode-i_size)) {
- handle_t *handle;
-
- handle = ext4_journal_start(inode, EXT4_HT_INODE, 3);
- if (IS_ERR(handle)) {
- error = PTR_ERR(handle);
- goto err_out;
- }
- if (ext4_handle_valid(handle)) {
- error = ext4_orphan_add(handle, inode);
- orphan = 1;
- }
- EXT4_I(inode)-i_disksize = attr-ia_size;
- rc = ext4_mark_inode_dirty(handle, inode);
- if (!error)
- error = rc;
- ext4_journal_stop(handle);
-
- if (ext4_should_order_data(inode)) {
- error = ext4_begin_ordered_truncate(inode,
+ if (S_ISREG(inode-i_mode)
+ (attr-ia_size inode-i_size)) {
+ if (ext4_should_order_data(inode)) {
+ error = ext4_begin_ordered_truncate(inode,
attr-ia_size);
- if (error) {
- /* Do as much error cleanup as possible */
- handle = ext4_journal_start(inode,
- EXT4_HT_INODE, 3);
- if (IS_ERR(handle)) {
- ext4_orphan_del(NULL, inode);
+ if (error)
goto err_out;
- }
- ext4_orphan_del(handle, inode);
- orphan = 0;
- ext4_journal_stop(handle);
+ }
+ handle = ext4_journal_start(inode, EXT4_HT_INODE, 3);
+ if (IS_ERR(handle)) {
+ error = PTR_ERR(handle);
goto err_out;
}
- }
- }
-
- if (attr-ia_valid ATTR_SIZE) {
- if (attr-ia_size != inode-i_size) {
- i_size_write(inode, attr-ia_size);
- /*
- * Blocks are going to be removed from the inode. Wait
- * for dio in flight. Temporarily disable
- * dioread_nolock to prevent livelock.
- */
- if (orphan) {
- if (!ext4_should_journal_data(inode)) {
- ext4_inode_block_unlocked_dio(inode);
- inode_dio_wait(inode);
- ext4_inode_resume_unlocked_dio(inode);
- } else
- ext4_wait_for_tail_page_commit(inode);
+ if (ext4_handle_valid(handle)) {
+ error = ext4_orphan_add(handle, inode);
+ orphan = 1;
}
+ down_write(EXT4_I(inode)-i_data_sem);
+ EXT4_I(inode)-i_disksize = attr-ia_size;
+ rc = ext4_mark_inode_dirty(handle, inode);
+ if (!error)
+ error = rc;
/*
- * Truncate pagecache after we've waited for commit
- * in data=journal mode to make pages freeable.
+ * We have to update i_size under i_data_sem together
+
Re: [PATCH RESEND 7/8] net: xilinx_emaclite: use platform_{get,set}_drvdata()
On 08/14/2013 05:40 AM, Libo Chen wrote:
We can use the wrapper functions platform_{get,set}_drvdata() instead of
dev_{get,set}_drvdata() with of_dev-dev, it is convenient for user.
Also, unnecessary dev_set_drvdata() is removed, because the driver core
clears the driver data to NULL after device_release or on probe failure.
Signed-off-by: Libo Chen libo.c...@huawei.com
Acked-by: Michal Simek mon...@monstr.eu
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] x86, apic: Enable x2APIC physical when cpu 256 native
* Youquan Song youquan.s...@linux.intel.com wrote: Firstly, please use the customary (multi-line) comment style: /* * Comment . * .. goes here. */ specified in Documentation/CodingStyle. Secondly, please send a patch against a vanilla (e.g. v3.11-rc5) kernel, as I've already zapped your previous patch from tip:x86/apic per your request. Hi Ingo, latest vanilla has no includes the patch yet, so I think it will be fine by only dropping it from tip tree. I know that it's not included yet - because I have not sent it to Linus. My suggestion was to document the circumstances here via a single patch, i.e. not a patch + revert-and-add-comments patch, but via a simple add-comments patch. Agreed? Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:sched/core] sched: Fix the theoretical signal_wake_up() vs. schedule() race
* Oleg Nesterov o...@redhat.com wrote: On 08/16, tip-bot for Oleg Nesterov wrote: Commit-ID: e4c711cfd32f3c74a699af3121a3b0ff631328a7 Gitweb: http://git.kernel.org/tip/e4c711cfd32f3c74a699af3121a3b0ff631328a7 Author: Oleg Nesterov o...@redhat.com AuthorDate: Tue, 13 Aug 2013 16:33:25 +0200 Committer: Ingo Molnar mi...@kernel.org CommitDate: Fri, 16 Aug 2013 17:44:54 +0200 sched: Fix the theoretical signal_wake_up() vs. schedule() race Ingo, thanks. But fyi, this is already merged as e0acd0a6 in Linus's tree. Missed that - I zapped this commit from the tip of sched/core, thanks Oleg! Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v2] mmc: sdhci-msm: Add support for MSM chipsets
Hi Georgi,
I found the you use the vreg-is_enabled.
why don't you use the regulator_is_enabled()? i think better that use this
function.
Is there a special reason that use the vreg-is_enabled?
Best Regards,
Jaehoon Chung
On 08/13/2013 11:06 PM, Georgi Djakov wrote:
This platform driver adds the support of Secure Digital Host
Controller Interface compliant controller in MSM chipsets.
CC: Asutosh Das asuto...@codeaurora.org
CC: Venkat Gopalakrishnan venk...@codeaurora.org
CC: Sahitya Tummala stumm...@codeaurora.org
CC: Subhash Jadavani subha...@codeaurora.org
Signed-off-by: Georgi Djakov gdja...@mm-sol.com
---
Changes from v1:
- GPIO references are replaced by pinctrl
- DT parsing is done mostly by mmc_of_parse()
- Use of_match_device() for DT matching
- A few minor changes
.../devicetree/bindings/mmc/sdhci-msm.txt | 62 ++
drivers/mmc/host/Kconfig | 13 +
drivers/mmc/host/Makefile |1 +
drivers/mmc/host/sdhci-msm.c | 813
4 files changed, 889 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-msm.txt
create mode 100644 drivers/mmc/host/sdhci-msm.c
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
new file mode 100644
index 000..4008f1f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
@@ -0,0 +1,62 @@
+* Qualcomm SDHCI controller (sdhci-msm)
+
+This file documents differences between the core properties in mmc.txt
+and the properties used by the sdhci-msm driver.
+
+Required properties:
+- compatible: should be qcom,sdhci-msm
+- reg: should contain SDHC, SD Core register map
+- reg-names: indicates various resources passed to driver (via reg proptery)
by name
+ reg-names examples are hc_mem and core_mem
+- interrupts: should contain SDHC interrupts
+- interrupt-names: indicates interrupts passed to driver (via interrupts
property) by name
+ interrupt-names examples are hc_irq and pwr_irq
+- supply-name-supply: phandle to the regulator device tree node
+ supply-name examples are vdd and vdd-io
+- pinctrl-names: Should contain only one value - default.
+- pinctrl-0: Should specify pin control groups used for this controller.
+
+Optional properties:
+- qcom,bus-speed-mode - specifies supported bus speed modes by host
+ The supported bus speed modes are :
+ HS200_1p8v - indicates that host can support HS200 at 1.8v
+ HS200_1p2v - indicates that host can support HS200 at 1.2v
+ DDR_1p8v - indicates that host can support DDR mode at 1.8v
+ DDR_1p2v - indicates that host can support DDR mode at 1.2v
+
+In the following, supply can be vdd (flash core voltage) or vdd-io (I/O
voltage).
+- qcom,supply-always-on - specifies whether supply should be kept on
always.
+- qcom,supply-lpm-sup - specifies whether supply can be kept in low power
mode (lpm).
+- qcom,supply-voltage-level - specifies voltage levels for supply. Should
be
+specified in pairs (min, max), units uV.
+- qcom,supply-current-level - specifies load levels for supply in lpm or
high power mode
+ (hpm). Should be specified in pairs (lpm, hpm), units uA.
+
+Example:
+
+ aliases {
+ sdhc1 = sdhc_1;
+ };
+
+ sdhc_1: qcom,sdhc@f9824900 {
+ compatible = qcom,sdhci-msm;
+ reg = 0xf9824900 0x11c, 0xf9824000 0x800;
+ reg-names = hc_mem, core_mem;
+ interrupts = 0 123 0, 0 138 0;
+ interrupt-names = hc_irq, pwr_irq;
+ bus-width = 4;
+ non-removable;
+
+ vdd-supply = pm8941_l21;
+ vdd-io-supply = pm8941_l13;
+ qcom,vdd-voltage-level = 295 295;
+ qcom,vdd-current-level = 9000 80;
+ qcom,vdd-io-always-on;
+ qcom,vdd-io-lpm-sup;
+ qcom,vdd-io-voltage-level = 180 295;
+ qcom,vdd-io-current-level = 6 22000;
+ qcom,bus-speed-mode = HS200_1p8v, DDR_1p8v;
+
+ pinctrl-names = default
+ pinctrl-0 = sdc1_clk sdc1_cmd sdc1_data;
+ };
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 8a4c066..2b31471 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -322,6 +322,19 @@ config MMC_ATMELMCI
If unsure, say N.
+config MMC_SDHCI_MSM
+ tristate Qualcomm SDHCI Controller Support
+ depends on ARCH_MSM
+ depends on MMC_SDHCI_PLTFM
+ help
+ This selects the Secure Digital Host Controller Interface (SDHCI)
+ support present in MSM SOCs from Qualcomm. The controller
+ supports SD/MMC/SDIO devices.
+
+ If you have a controller with this interface, say Y or M here.
+
+ If unsure, say N.
+
config MMC_MSM
tristate Qualcomm SDCC
Re: [RFC v1 5/5] ARM: mvebu: add board init for Armada 1500
On Monday 19 August 2013, Sebastian Hesselbarth wrote: Note that we should really change the common code to do both the of_clk_init() and the l2x0_of_init() automatically, but that needs to be done with some care, in order to not break any of the existing platforms. Would you be able to do one of the two? We can then get the next person that wants to add a platform to do the last one ;-) Scary but that reduces armada-1500.c to MACH descriptor and DT compatible only ;) I don't expect any weird hacks required for it anyway. You will need the .smp_ops pointer once you add SMP support. Other than that, if your machine descriptor only has the pointer to the compatible strings, you can actually build without a machine descriptor (as we do on arm64). The string is used only in /proc/cpuinfo then. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Aug 19
Hi all, Changes since 20130816: Changed tree: the device-mapper tree is now a git tree (instead of a quilt series) The libata tree gained a build failure do I used the version from next-20130816. The wireless-next tree gained a conflict against the wireless tree. The tip tree gained a conflict against the pm tree. The akpm-current tree gained a conflict against the ext4 tree. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use git pull to do so as that will try to merge the new linux-next release with the old one. You should use git fetch as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 222 trees (counting Linus' and 30 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (b36f4be Linux 3.11-rc6) Merging fixes/master (b3a3a9c Merge tag 'trace-3.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace) Merging kbuild-current/rc-fixes (ad81f05 Linux 3.11-rc1) Merging arc-current/for-curr (c095ba7 Linux 3.11-rc4) Merging arm-current/fixes (2a28224 Merge branch 'security-fixes' into fixes) Merging m68k-current/for-linus (ea077b1 m68k: Truncate base in do_div()) Merging metag-fixes/fixes (dfe248b MAINTAINERS: add linux-metag mailing list) Merging powerpc-merge/merge (28e61cc powerpc/tm: Fix context switching TAR, PPR and DSCR SPRs) Merging sparc/master (1c2696c sparc64: Fix ITLB handler of null page) Merging net/master (0f7dd1a Merge tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mturquette/linux) Merging ipsec/master (0ea9d5e xfrm: introduce helper for safe determination of mtu) Merging sound-current/for-linus (1801928 ALSA: hda - Add a fixup for Gateway LT27) Merging pci-current/for-linus (36dd1f3 PCI: mvebu: Disable prefetchable memory support in PCI-to-PCI bridge) Merging wireless/master (48c3e37 Merge branch 'for-john' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211) Merging driver-core.current/driver-core-linus (5ae90d8 Linux 3.11-rc3) Merging tty.current/tty-linus (c095ba7 Linux 3.11-rc4) Merging usb.current/usb-linus (ff8a43c USB: keyspan: fix null-deref at disconnect and release) Merging staging.current/staging-linus (d4e4ab8 Linux 3.11-rc5) Merging char-misc.current/char-misc-linus (5ae90d8 Linux 3.11-rc3) Merging input-current/for-linus (88ce3c3 Merge branch 'next' into for-linus) Merging md-current/for-linus (f94c0b6 md/raid5: fix interaction of 'replace' and 'recovery'.) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (e70308e Revert crypto: crct10dif - Wrap crc_t10dif function all to use crypto transform framework) Merging ide/master (6d128e1 Revert Makefile: Fix install error with make -j option) Merging dwmw2/master (5950f08 pcmcia: remove RPX board stuff) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging devicetree-current/devicetree/merge (cf9e236 of/irq: init struct resource to 0 in of_irq_to_resource()) Merging rr-fixes/fixes (6c2580c Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/egtvedt/linux-avr32) Merging mfd-fixes/master (5649d8f mfd: ab8500-sysctrl: Let sysctrl driver work without pdata) Merging vfio-fixes/for-linus (d24cdbf vfio-pci: Avoid deadlock on remove) Merging drm-intel-fixes/drm-intel-fixes (884020b drm/i915: Invalidate TLBs for
Re: [PATCH v4 20/28] x86, irq: More strict checking about registering ioapic
2013/8/11 Yinghai Lu ying...@kernel.org
1. check overlaping gsi range
for hot-add ioapic case, BIOS may have some entries in MADT
and also have setting in pci root bus with _GSB of DSDT.
2. check if entries is in right range.
Signed-off-by: Yinghai Lu ying...@kernel.org
Cc: Joerg Roedel j...@8bytes.org
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
arch/x86/kernel/apic/io_apic.c | 30 --
1 file changed, 24 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index b026cc7..60c6706 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -3818,12 +3818,9 @@ void __init ioapic_insert_resources(void)
}
}
-int mp_find_ioapic(u32 gsi)
+static int __mp_find_ioapic(u32 gsi)
{
- int i = 0;
-
- if (nr_ioapics == 0)
- return -1;
+ int i;
/* Find the IOAPIC that manages this GSI. */
for_each_ioapic(i) {
@@ -3833,10 +3830,19 @@ int mp_find_ioapic(u32 gsi)
return i;
}
- printk(KERN_ERR ERROR: Unable to locate IOAPIC for GSI %d\n, gsi);
return -1;
}
+int mp_find_ioapic(u32 gsi)
+{
+ int ret = __mp_find_ioapic(gsi);
+
+ if (ret == -1)
+ pr_err(ERROR: Unable to locate IOAPIC for GSI %d\n, gsi);
+
+ return ret;
+}
+
int mp_find_ioapic_pin(int ioapic, u32 gsi)
{
struct mp_ioapic_gsi *gsi_cfg;
@@ -3888,6 +3894,11 @@ void __init mp_register_ioapic(int id, u32 address,
u32 gsi_base)
if (bad_ioapic(address))
return;
+ /* already registered ? */
+ idx = __mp_find_ioapic(gsi_base);
+ if (idx = 0)
+ return;
+
idx = find_first_zero_bit(ioapics_mask, MAX_IO_APICS);
if (idx = MAX_IO_APICS) {
pr_warn(WARNING: Max # of I/O APICs (%d) exceeded,
skipping\n,
@@ -3914,6 +3925,13 @@ void __init mp_register_ioapic(int id, u32 address,
u32 gsi_base)
* and to prevent reprogramming of IOAPIC pins (PCI GSIs).
*/
entries = io_apic_get_redir_entries(idx);
entries is possible to be 0? io_apic_get_redir_entries() returns
reg_01.bits.entries + 1
as entries.
+
+ if (!entries || entries MP_MAX_IOAPIC_PIN) {
+ clear_fixmap(FIX_IO_APIC_BASE_0 + idx);
+ memset(ioapics[idx], 0, sizeof(struct ioapic));
+ return;
+ }
+
gsi_cfg = mp_ioapic_gsi_routing(idx);
gsi_cfg-gsi_base = gsi_base;
gsi_cfg-gsi_end = gsi_base + entries - 1;
--
1.8.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best regards
Tianyu Lan
--
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 v1 5/5] ARM: mvebu: add board init for Armada 1500
On Monday 19 August 2013, Sebastian Hesselbarth wrote: AFAIK, there is Armada 1500 (88de3100) used in every Google TV 2nd Gen devices, some older multimedia boxes also used Armada 1000 (88de3010), and Chromecast comprises Armada 1500-mini (88de3005). According to the chromecast kernel sources (which seem to have all the gtv stuff in them), they changed the CPU core between minor versons of the 88de3100: PJ4 based: - MV88DE3100_BG2_A0 - MV88DE3100_BG2_A1 Cortex-A5 or Cortex-A9 based: - MV88DE3100_BG2_CD - MV88DE3100_BG2_CZ - MV88DE3100_BG3 Those are Kconfig strings, I don't know how those correspond to chip identification registers or labels printed on the SoC package. We should be able to find out if it is PJ4B or Cortex-A9 by checking any CPU register? /proc/cpuinfo will tell you what core you have, see http://wiki.casthacks.com/index.php?title=Google_ChromeCast_Specs: CPU implementer : 0x41 # 0x41 == ARM Ltd CPU architecture: 7# 0x07 == ARMv7 CPU variant : 0x3 # 0x03 == Core revision r3 CPU part: 0xc09# 0xc0? == Cortex-A?, 0xc09 == A9 CPU revision: 0# 0x00 == minor revision r3p0 On http://forum.gtvhacker.com/star-vap430-f40/topic972.html, I found this for a PJ4 based 88de3100: CPU implementer : 0x56 CPU architecture: 7 CPU variant : 0x2 CPU part: 0x584 CPU revision: 1 Comparing those to other bits I found on the web, it actually seems to be a PJ4B rather than the original PJ4. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.11-rc6 genetlink locking fix offends lockdep
3.11-rc6's commit 58ad436fcf49 (genetlink: fix family dump race)
gives me the lockdep trace below at startup.
Hmm. Yes, I see now how this happens, not sure why I didn't run into it.
The problem is that genl_family_rcv_msg() is called with the genl_lock
held, and then calls netlink_dump_start() with it held, creating a
genl_lock-cb_mutex dependency, but obviously the dump continuation is
the other way around.
We could use the semaphore instead, I believe, but I don't really
understand the mutex vs. semaphore well enough to be sure that's
correct.
johannes
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index f85f8a2..6cfa646 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -792,7 +792,7 @@ static int ctrl_dumpfamily(struct sk_buff *skb, struct
netlink_callback *cb)
bool need_locking = chains_to_skip || fams_to_skip;
if (need_locking)
- genl_lock();
+ down_read(cb_lock);
for (i = chains_to_skip; i GENL_FAM_TAB_SIZE; i++) {
n = 0;
@@ -815,7 +815,7 @@ errout:
cb-args[1] = n;
if (need_locking)
- genl_unlock();
+ up_read(cb_lock);
return skb-len;
}
--
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 v1 0/5] ARM: Initial support for Marvell Armada 1500
On Monday 19 August 2013, Sebastian Hesselbarth wrote: We either put it into mach-mvebu and pretend to consolidate Marvell SoCs in there. Pro would be that it is close to other Armadas there, con is that Armada is codename for virtually any Marvell SoC lately. If we want a new mach- directory, I'd suggest either mach-berlin which looks like some nickname for 88de3xxx SoCs or simply boring mach-88de3xxx. As I said, either way is fine with me. If you use a new directory, I'd suggest using the same mach-mv88de3100 name that Marvell uses, to give them a hint about this when updating their own sources to a newer version. They might get the idea and actually start using your code ;-) Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [BUGFIX] crash/ioapic: Prevent crash_kexec() from deadlocking of ioapic_lock
Prevent crash_kexec() from deadlocking of ioapic_lock. When crash_kexec()
is executed on a cpu, the cpu will get ioapic_lock in disable_IO_APIC().
So if the cpu gets NMI while locking ioapic_lock, a deadlock wiil happen.
In this patch, ioapic_lock is initialized before disable_IO_APIC().
To confirm this deadlocking, you'll set up as follows:
1. Add mdelay(1000) after raw_spin_lock_irqsave() in
native_ioapic_set_affinity()@arch/x86/kernel/apic/io_apic.c
Although the deadlocking can occur without this modification, it will
increase the potential of the deadlocking problem.
2. Build and install the kernel
3. Set up the OS which will run panic() and kexec when NMI is injected
# echo kernel.unknown_nmi_panic=1 /etc/sysctl.conf
# vim /etc/default/grub
add nmi_watchdog=0 crashkernel=256M in GRUB_CMDLINE_LINUX line
# grub2-mkconfig
4. Reboot the OS
5. Run following command for each vcpu on the guest
# while true; do echo CPU num /proc/irq/IO-APIC-edge or
IO-APIC-fasteoi/smp_affinitity; done;
By running this command, cpus will get ioapic_lock for setting affinity.
6. Inject NMI (push a dump button or execute 'virsh inject-nmi domain' if you
use VM)
After injecting NMI, panic() is called in an nmi-handler context.
Then, kexec will normally run in panic(), but the operation will be stopped
by deadlock of ioapic_lock in crash_kexec()-machine_crash_shutdown()-
native_machine_crash_shutdown()-disable_IO_APIC()-clear_IO_APIC()-
clear_IO_APIC_pin()-ioapic_read_entry().
Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: x...@kernel.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: Andi Kleen a...@linux.intel.com
Cc: Seiji Aguchi seiji.agu...@hds.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Sebastian Andrzej Siewior sebast...@breakpoint.cc
Cc: Joerg Roedel j...@8bytes.org
Cc: Zhang Yanfei zhangyan...@cn.fujitsu.com
Cc: Eric W. Biederman ebied...@xmission.com
Cc: Gleb Natapov g...@redhat.com
Cc: Marcelo Tosatti mtosa...@redhat.com
Cc: linux-kernel@vger.kernel.org
Cc: sta...@vger.kernel.org
---
arch/x86/include/asm/apic.h|2 ++
arch/x86/kernel/apic/io_apic.c |5 +
arch/x86/kernel/crash.c|4
3 files changed, 11 insertions(+)
diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index f8119b5..ddb06af 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -715,4 +715,6 @@ static inline void exiting_ack_irq(void)
ack_APIC_irq();
}
+extern void ioapic_lock_init(void);
+
#endif /* _ASM_X86_APIC_H */
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 9ed796c..2816c07 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1534,6 +1534,11 @@ void intel_ir_io_apic_print_entries(unsigned int apic,
}
}
+void ioapic_lock_init(void)
+{
+ raw_spin_lock_init(ioapic_lock);
+}
+
__apicdebuginit(void) print_IO_APIC(int ioapic_idx)
{
union IO_APIC_reg_00 reg_00;
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 74467fe..ea039d5 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -129,6 +129,10 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
lapic_shutdown();
#if defined(CONFIG_X86_IO_APIC)
+ /*
+* Prevent crash_kexec() from deadlocking of ioapic_lock.
+*/
+ ioapic_lock_init();
disable_IO_APIC();
#endif
#ifdef CONFIG_HPET_TIMER
--
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: dmaengine: make dma_channel_rebalance() NUMA aware
On Wed, Jul 31, 2013 at 4:13 AM, Brice Goglin brice.gog...@inria.fr wrote:
dmaengine: make dma_channel_rebalance() NUMA aware
dma_channel_rebalance() currently distributes channels by processor ID.
These IDs often change with the BIOS, and the order isn't related to
the DMA channel list (related to PCI bus ids).
* On my SuperMicro dual E5 machine, first socket has processor IDs [0-7]
(and [16-23] for hyperthreads), second socket has [8-15]+[24-31]
= channels are properly allocated to local CPUs.
* On Dells R720 with same processors, first socket has even processor IDs,
second socket has odd numbers
= half the processors get channels on the remote socket, causing
cross-NUMA traffic and lower DMA performance.
Change nth_chan() to return the channel with min table_count and in the
NUMA node of the given CPU, if any. If none, the (non-local) channel with
min table_count is returned. nth_chan() is therefore renamed into min_chan()
since we don't iterate until the nth channel anymore. In practice, the
behavior is the same because first channels are taken first and are then
ignored because they got an additional reference.
The new code has a slightly higher complexity since we always scan the
entire list of channels for finding the minimal table_count (instead
of stopping after N chans), and because we check whether the CPU is in the
DMA device locality mask. Overall we still have time complexity =
number of chans x number of processors. This rebalance is rarely used,
so this won't hurt.
On the above SuperMicro machine, channels are still allocated the same.
On the Dells, there are no locality issue anymore (each MEMCPY channel
goes to both hyperthreads of a single core of the local socket).
Signed-off-by: Brice Goglin brice.gog...@inria.fr
---
drivers/dma/dmaengine.c | 64
+++-
1 file changed, 37 insertions(+), 27 deletions(-)
Index: b/drivers/dma/dmaengine.c
===
--- a/drivers/dma/dmaengine.c 2013-07-29 05:53:33.0 +0200
+++ b/drivers/dma/dmaengine.c 2013-07-31 13:02:34.640590036 +0200
@@ -376,20 +376,35 @@ void dma_issue_pending_all(void)
EXPORT_SYMBOL(dma_issue_pending_all);
/**
- * nth_chan - returns the nth channel of the given capability
+ * dma_chan_is_local - returns 1 if the channel is close to the cpu
Might as well be explicit and say returns true if the channel is in
the same numa-node as the cpu.
+ */
+static int dma_chan_is_local(struct dma_chan *chan, int cpu)
Make it return bool since it's an is routine.
+{
+#ifdef CONFIG_NUMA
+ int node = dev_to_node(chan-device-dev);
+ return node == -1 || cpumask_test_cpu(cpu, cpumask_of_node(node));
+#else
+ return 1;
+#endif
The ifdef is not necessary as dev_to_node() returns -1 in the !CONFIG_NUMA case.
+}
+
+/**
+ * min_chan - returns the channel with min count and close to the cpu
same as above replace close with same numa-node.
* @cap: capability to match
- * @n: nth channel desired
+ * @cpu: cpu index which the channel should be close to
*
- * Defaults to returning the channel with the desired capability and the
- * lowest reference count when 'n' cannot be satisfied. Must be called
- * under dma_list_mutex.
+ * If some channels are close to the given cpu, the one with the lowest
+ * reference count is returned. Otherwise, cpu is ignored and only the
+ * reference count is taken into account.
I think we can drop these comments and the distinction, see below.
+ * Must be called under dma_list_mutex.
*/
-static struct dma_chan *nth_chan(enum dma_transaction_type cap, int n)
+static struct dma_chan *min_chan(enum dma_transaction_type cap, int cpu)
{
struct dma_device *device;
struct dma_chan *chan;
struct dma_chan *ret = NULL;
struct dma_chan *min = NULL;
+ struct dma_chan *localmin = NULL;
list_for_each_entry(device, dma_device_list, global_node) {
if (!dma_has_cap(cap, device-cap_mask) ||
@@ -398,22 +413,18 @@ static struct dma_chan *nth_chan(enum dm
list_for_each_entry(chan, device-channels, device_node) {
if (!chan-client_count)
continue;
- if (!min)
- min = chan;
- else if (chan-table_count min-table_count)
+ if (!min || chan-table_count min-table_count)
min = chan;
- if (n-- == 0) {
- ret = chan;
- break; /* done */
- }
+ if (cpu != -1 dma_chan_is_local(chan, cpu))
+ if (!localmin ||
+ chan-table_count localmin-table_count)
+
Re: UEFI Plugfest 2013 -- New Orleans
On Fri, 2013-08-16 at 11:20 -0400, John W. Linville wrote: All, The Linux Foundation and The UEFI Forum are hosting a UEFI Plugfest event in New Orleans on September 19-20, 2013. This event will run concurrent with Linux Plumbers Conference, just after LinuxCon at the Hyatt Regency New Orleans. Hm. It would be really useful to have a kernel build option which *disables* all the workarounds we've ever put in for broken firmware. Every deviation from the spec (or common sense), however minor, should show up as a clear failure. Even the ones we *have* been able to work around, because we still want them *fixed*. And there's a school of thought that says we should brick as many Samsung machines as possible, if they actually turn up without having fixed that. A stress test for the NV storage is actually a really good idea... -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
[PATCH v2] dmaengine: make dmatest less noisy
Commit 95019c8c5 dmatest: gather test results in the linked list started to warning whenever we add results to a test thread. A warning for something completely normal? This is just cluttering my terminal. Move to debug prints. Cc: Andy Shevchenko andriy.shevche...@linux.intel.com Signed-off-by: Linus Walleij linus.wall...@linaro.org --- ChangeLog v1-v2: - Instead of flat out deleting this, move it to debug. --- drivers/dma/dmatest.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c index e88ded2..e1dc005 100644 --- a/drivers/dma/dmatest.c +++ b/drivers/dma/dmatest.c @@ -36,7 +36,7 @@ static char test_device[20]; module_param_string(device, test_device, sizeof(test_device), S_IRUGO); MODULE_PARM_DESC(device, Bus ID of the DMA Engine to test (default: any)); -static unsigned int threads_per_chan = 1; +static unsigned int threads_per_chan = 8; module_param(threads_per_chan, uint, S_IRUGO); MODULE_PARM_DESC(threads_per_chan, Number of threads to start per channel (default: 1)); @@ -406,7 +406,7 @@ static int thread_result_add(struct dmatest_info *info, list_add_tail(tr-node, r-results); mutex_unlock(info-results_lock); - pr_warn(%s\n, thread_result_get(r-name, tr)); + pr_debug(%s\n, thread_result_get(r-name, tr)); return 0; } -- 1.8.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/
Fwd: [arch/powerpc/sysdev/fsl_lbc.c] Elbc read/write driver
Hi, I'm working on a freescale qoriq p3041 and trying to communicate with a device by elbc bus in gpmc mode. I 've integrated CONFIG_FSL_LBC in Linux which provide the basics functions I guess. Now I'm wondering how can I do read and write operations on the bus. Should I code .read and .write driver functions?How can I start? How integrates my device in the device tree? thanks a lot, Best Regards, -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] dmaengine: make dmatest less noisy
On Mon, 2013-08-19 at 10:25 +0200, Linus Walleij wrote: Commit 95019c8c5 dmatest: gather test results in the linked list started to warning whenever we add results to a test thread. A warning for something completely normal? This is just cluttering my terminal. Move to debug prints. [] diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c [] @@ -36,7 +36,7 @@ static char test_device[20]; module_param_string(device, test_device, sizeof(test_device), S_IRUGO); MODULE_PARM_DESC(device, Bus ID of the DMA Engine to test (default: any)); -static unsigned int threads_per_chan = 1; +static unsigned int threads_per_chan = 8; module_param(threads_per_chan, uint, S_IRUGO); MODULE_PARM_DESC(threads_per_chan, Number of threads to start per channel (default: 1)); This is unrelated and makes the MODULE_PARAM_DESC below it have the incorrect default. @@ -406,7 +406,7 @@ static int thread_result_add(struct dmatest_info *info, list_add_tail(tr-node, r-results); mutex_unlock(info-results_lock); - pr_warn(%s\n, thread_result_get(r-name, tr)); + pr_debug(%s\n, thread_result_get(r-name, tr)); return 0; } This bit is sensible though. -- 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/1] extcon: arizona: Fix a typo in a comment
On 08/05/2013 06:00 PM, Sachin Kamat wrote:
Fixes an incomplete comment introduced by commit 9c2ba270
(extcon: arizona: Simplify HPDET based identification).
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/extcon/extcon-arizona.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index e557130..5061ae5 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -514,7 +514,7 @@ static int arizona_hpdet_do_id(struct arizona_extcon_info
*info, int *reading,
}
/*
- * If we measure the mic as
+ * If we measure the mic as high impedance
*/
if (!id_gpio || info-hpdet_res[1] 50) {
dev_dbg(arizona-dev, Detected mic\n);
Applied it.
Thanks,
Chanwoo Choi
--
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] extcon: palmas: Modified the compatible type to *ti,palmas-usb-vid*
On 08/19/2013 02:05 PM, Kishon Vijay Abraham I wrote: Hi, On Saturday 17 August 2013 03:51 AM, Stephen Warren wrote: On 08/16/2013 04:20 AM, Kishon Vijay Abraham I wrote: The Palmas device contains only a USB VID detector, so modified the compatible type to *ti,palmas-usb-vid*. diff --git a/Documentation/devicetree/bindings/extcon/extcon-palmas.txt b/Documentation/devicetree/bindings/extcon/extcon-palmas.txt PALMAS USB COMPARATOR Required Properties: - - compatible : Should be ti,palmas-usb or ti,twl6035-usb + - compatible : Should be ti,palmas-usb-vid. Has the old value been published in a release kernel? If so, it makes No. This was merged only in 3.11-rc1. So I think we should take this version? Chanwoo can you take this patch? This patch will be included in 3.12-rc* after 3.12-rc1. and this patch is applied on extcon-linus branch. Thanks, Chanwoo Choi -- 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 RFC v2] mmc: sdhci-msm: Add support for MSM chipsets
Hi Jaehoon,
Thank you for noticing this and providing feedback. I will make it use
the framework function.
BR,
Georgi
On 08/19/2013 10:27 AM, Jaehoon Chung wrote:
Hi Georgi,
I found the you use the vreg-is_enabled.
why don't you use the regulator_is_enabled()? i think better that use this
function.
Is there a special reason that use the vreg-is_enabled?
Best Regards,
Jaehoon Chung
On 08/13/2013 11:06 PM, Georgi Djakov wrote:
This platform driver adds the support of Secure Digital Host
Controller Interface compliant controller in MSM chipsets.
CC: Asutosh Das asuto...@codeaurora.org
CC: Venkat Gopalakrishnan venk...@codeaurora.org
CC: Sahitya Tummala stumm...@codeaurora.org
CC: Subhash Jadavani subha...@codeaurora.org
Signed-off-by: Georgi Djakov gdja...@mm-sol.com
---
Changes from v1:
- GPIO references are replaced by pinctrl
- DT parsing is done mostly by mmc_of_parse()
- Use of_match_device() for DT matching
- A few minor changes
.../devicetree/bindings/mmc/sdhci-msm.txt | 62 ++
drivers/mmc/host/Kconfig | 13 +
drivers/mmc/host/Makefile |1 +
drivers/mmc/host/sdhci-msm.c | 813
4 files changed, 889 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-msm.txt
create mode 100644 drivers/mmc/host/sdhci-msm.c
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
new file mode 100644
index 000..4008f1f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
@@ -0,0 +1,62 @@
+* Qualcomm SDHCI controller (sdhci-msm)
+
+This file documents differences between the core properties in mmc.txt
+and the properties used by the sdhci-msm driver.
+
+Required properties:
+- compatible: should be qcom,sdhci-msm
+- reg: should contain SDHC, SD Core register map
+- reg-names: indicates various resources passed to driver (via reg proptery)
by name
+ reg-names examples are hc_mem and core_mem
+- interrupts: should contain SDHC interrupts
+- interrupt-names: indicates interrupts passed to driver (via interrupts
property) by name
+ interrupt-names examples are hc_irq and pwr_irq
+- supply-name-supply: phandle to the regulator device tree node
+ supply-name examples are vdd and vdd-io
+- pinctrl-names: Should contain only one value - default.
+- pinctrl-0: Should specify pin control groups used for this controller.
+
+Optional properties:
+- qcom,bus-speed-mode - specifies supported bus speed modes by host
+ The supported bus speed modes are :
+ HS200_1p8v - indicates that host can support HS200 at 1.8v
+ HS200_1p2v - indicates that host can support HS200 at 1.2v
+ DDR_1p8v - indicates that host can support DDR mode at 1.8v
+ DDR_1p2v - indicates that host can support DDR mode at 1.2v
+
+In the following, supply can be vdd (flash core voltage) or vdd-io (I/O
voltage).
+- qcom,supply-always-on - specifies whether supply should be kept on
always.
+- qcom,supply-lpm-sup - specifies whether supply can be kept in low power
mode (lpm).
+- qcom,supply-voltage-level - specifies voltage levels for supply. Should be
+specified in pairs (min, max), units uV.
+- qcom,supply-current-level - specifies load levels for supply in lpm or
high power mode
+ (hpm). Should be specified in pairs (lpm, hpm), units uA.
+
+Example:
+
+ aliases {
+ sdhc1 = sdhc_1;
+ };
+
+ sdhc_1: qcom,sdhc@f9824900 {
+ compatible = qcom,sdhci-msm;
+ reg = 0xf9824900 0x11c, 0xf9824000 0x800;
+ reg-names = hc_mem, core_mem;
+ interrupts = 0 123 0, 0 138 0;
+ interrupt-names = hc_irq, pwr_irq;
+ bus-width = 4;
+ non-removable;
+
+ vdd-supply = pm8941_l21;
+ vdd-io-supply = pm8941_l13;
+ qcom,vdd-voltage-level = 295 295;
+ qcom,vdd-current-level = 9000 80;
+ qcom,vdd-io-always-on;
+ qcom,vdd-io-lpm-sup;
+ qcom,vdd-io-voltage-level = 180 295;
+ qcom,vdd-io-current-level = 6 22000;
+ qcom,bus-speed-mode = HS200_1p8v, DDR_1p8v;
+
+ pinctrl-names = default
+ pinctrl-0 = sdc1_clk sdc1_cmd sdc1_data;
+ };
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 8a4c066..2b31471 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -322,6 +322,19 @@ config MMC_ATMELMCI
If unsure, say N.
+config MMC_SDHCI_MSM
+ tristate Qualcomm SDHCI Controller Support
+ depends on ARCH_MSM
+ depends on MMC_SDHCI_PLTFM
+ help
+ This selects the Secure Digital Host Controller Interface (SDHCI)
+ support present in MSM SOCs from Qualcomm. The controller
+ supports SD/MMC/SDIO devices.
+
+ If you
RE: [PATCH] block: support embedded device command line partition
On 08/15/2013 08:54 PM, Caizhiyong wrote: +blkdevparts=blkdev-def[;blkdev-def] + blkdev-def := blkdev-id:partdef[,partdef] +partdef := size[@offset](part-name) + +blkdev-id +block device disk name, embedded device used fixed block device, +it's disk name also fixed. such as: mmcblk0, mmcblk1, mmcblk0boot0. The device-name isn't always fixed. For example, what if there are multiple SDHCI controllers, one hosting a fixed eMMC device and the other an SD card? It's quite typical for the eMMC's device name (which is likely what should be affected by this feature) to be mmcblk0 when no SD card is present, yet be mmcblk1 when an SD card is present. Is there a more precise/stable way to define which device the command-line option applies to? Yes. Fixed is for single controller. For multiple controllers, currently, there is not a simple way. I tend to do something in the eMMC driver, such as initialize order, but I have not tried. There have been proposals before to try and create a fixed naming for the controllers (or rather the block devices they generate...) but they've been rejected. I don't think we should rely on being able to do that. + +offset +partition start address, in bytes. + +(part-name) +partition name, kernel send uevent with PARTNAME. application can create +a link to block device partition with the name PARTNAME. +user space application can access partition by partition name. Do partitions usually have a PARTNAME attribute when probed through normal mechanisms like MBR? If so, I guess this is fine. Perhaps we can just use , as the delimiter for all fields, rather than special-casing part-name to use (), so: size,offset,partname,size,offset,partname,... The partname field could easily be empty if not needed. If no need partname, your bootargs are mmcblk0:1G,1G,1G,... Well, you always need the offset too. I don't think there's any harm in forcing all fields to be specified in all cases; it makes the whole system much more regular and less error-prone. Alternatively, use a different separator between fields for a given partition, and between partitions, e.g.: size,offset,partname;size,offset,partname That way, you know that if you see a ; you're looking at a new partition, and hence the partname field need not always be specified. Although, if you want to specify a partname but not an offset you'd still need empty fields, so just requiring all fields to always be present still seems safest to me. I just follow MTD cmdline partition format.(reference drivers/mtd/cmdlinepart.c) There are many pitfalls in using this partition format, the designer is more consideration its ease of use, rather than safe. There is an other conversation: https://lkml.org/lkml/2013/8/3/16 -- 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] dmaengine: make dmatest less noisy
On Mon, 2013-08-19 at 10:25 +0200, Linus Walleij wrote: Commit 95019c8c5 dmatest: gather test results in the linked list started to warning whenever we add results to a test thread. A warning for something completely normal? This is just cluttering my terminal. Move to debug prints. Cc: Andy Shevchenko andriy.shevche...@linux.intel.com Signed-off-by: Linus Walleij linus.wall...@linaro.org --- a/drivers/dma/dmatest.c +++ b/drivers/dma/dmatest.c @@ -406,7 +406,7 @@ static int thread_result_add(struct dmatest_info *info, list_add_tail(tr-node, r-results); mutex_unlock(info-results_lock); - pr_warn(%s\n, thread_result_get(r-name, tr)); + pr_debug(%s\n, thread_result_get(r-name, tr)); This is the idea behind original DMATEST module logic. As far as I understand we would like to have them as warnings in case when driver is compiled in and tests are run from the beginning. Though, I sent a correction patch that moves No error messages to debug level which, I think, makes sense. I don't know why Dan still keep silent on my last message in the discussion [1]. [1] http://www.spinics.net/lists/kernel/msg1581822.html -- Andy Shevchenko andriy.shevche...@linux.intel.com Intel Finland Oy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] mtd: m25p80: make CONFIG_M25PXX_USE_FAST_READ safe to enable
On Sat, Aug 17, 2013 at 01:17:02PM -0700, Brian Norris wrote: On Mon, Aug 12, 2013 at 12:22:24PM +0200, Sascha Hauer wrote: This patch adds a flag to struct flash_info indicating that fast_read is not supported. This now gives the following logic when determing whether to enable fastread: 1) enable fast_read if device node contains m25p,fast-read 2) enable fast_read unconditionally if forced in Kconfig 3) Disable fast_read if the chip does not support it This logic is either unclear or incorrect. This makes enabling CONFIG_M25PXX_USE_FAST_READ a safe option since we no longer enable the fast_read option unconditionally. This statement seems to contradict 2 above, depending on the reading (how can 2 enable unconditionally, yet CONFIG_..._FAST_READ no longer enable[s] ... unconditionally?). The problem I have with this description is that it is assuming that 1, 2, and 3 are applied sequentially, so that later items in the sequence have higher precedence. So it's describing code ordering, not really logic. And statement 3 weakens the unconditionally of 2. And to avoid simply complaining, I propose an alternative explanation: If the flash chip does not support fast_read, then disable it. Otherwise: 1) enable fast_read if device node contains m25p,fast-read 2) enable fast_read if forced in Kconfig If we correct this description, then: Acked-by: Brian Norris computersforpe...@gmail.com I can edit the patch and push the whole thing if this is acceptable. Yes, that would be great. Your explanation sounds better than mine. One related question (not required for this series): do we even need Kconfig M25PXX_USE_FAST_READ any more? Are there any SPI controllers that can't use FAST_READ? Or perhaps if they have a slow clock, it's preferable to use normal read? If there are no restrictions from the controller side, I think this NO_FR flag gives enough information to determine everything at runtime, not compile-time. This M25PXX_USE_FAST_READ is a no-go for multiplatform Kernels and should be removed. I have no idea though how we can do this without risking regressions since we have no idea who intentionally disabled this option. Maybe we just have to find out by removing it and waiting for people to complain^B^B^Bsend patches. 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/
Re: [RFC v1 4/5] ARM: mvebu: add Armada 1500 and Sony NSZ-GS7 device tree files
On Monday 19 August 2013, Sebastian Hesselbarth wrote: On 08/17/2013 09:28 PM, Arnd Bergmann wrote: On Friday 16 August 2013, Sebastian Hesselbarth wrote: This seems like a strange combination. I would have expected either PJ4+Aurora+apbtimer or A9+pl310+localtimer, based on what I found in the chromecast kernel source. Do you have more information here about what is used on the two variants? I have no clue, what combination it really is. Unfortunately, Marvell didn't release any open datasheets, of course. I can only look at GPL'd Asus Cube kernel, I used for getting an idea of what was required for initial support and reg offsets, irqs and friends. They bring up twd as localtimer. Also, grep'ing the Cube kernel sources in mach-mv88de3100 gives hits for CONFIG_PJ4 (note the missing B), l2x0, smp_twd, apb_timer. No hits for pl310, A9. I found this snippet in Kconfig for the Chromecast: config ARCH_MV88DE3100_BG2 bool BG2 family help Support for Marvell BG2 processors, based on the Marvell PJ4B CPU and the Marvell TAUROS3 L2 cache controller, or the ARM CortexA9 CPU and the ARM PL310 L2 cache controller config ARCH_MV88DE3100_BG3 bool BG3 family help Support for Marvell BG3 processors, based on the ARM CortexA9MP CPU and the ARM PL310 L2 cache controller A9 will always work when CPU_V7 is set, it doesn't have a Kconfig option. When CPU_PJ4 is set, it will work on both. Regarding the other options, this is what I found from the defconfigs in chromecast: $ git grep LOCAL_TIMER arch/arm/configs/*mv88* arch/arm/configs/mv88de3100_ax_android_defconfig:CONFIG_LOCAL_TIMERS=y arch/arm/configs/mv88de3100_ax_defconfig.bg2:CONFIG_LOCAL_TIMERS=y arch/arm/configs/mv88de3100_ax_emmc_android_defconfig:CONFIG_LOCAL_TIMERS=y arch/arm/configs/mv88de3100_ax_linux_defconfig:CONFIG_LOCAL_TIMERS=y $ git grep CONFIG_SMP= arch/arm/configs/*mv88* arch/arm/configs/mv88de3100_ax_android_defconfig:CONFIG_SMP=y arch/arm/configs/mv88de3100_ax_defconfig.bg2:CONFIG_SMP=y arch/arm/configs/mv88de3100_ax_emmc_android_defconfig:CONFIG_SMP=y arch/arm/configs/mv88de3100_ax_linux_defconfig:CONFIG_SMP=y $ git grep CPU_PJ4 arch/arm/configs/*mv88* arch/arm/configs/eureka_mv88de31xx_defconfig:CONFIG_CPU_PJ4=y arch/arm/configs/mv88de3100_ax_android_defconfig:CONFIG_CPU_PJ4=y arch/arm/configs/mv88de3100_ax_bg2a0_rdkdmp_dongle_defconfig:CONFIG_CPU_PJ4=y arch/arm/configs/mv88de3100_ax_defconfig.bg2:CONFIG_CPU_PJ4=y arch/arm/configs/mv88de3100_ax_defconfig.bg2cd_dmp:CONFIG_CPU_PJ4=y arch/arm/configs/mv88de3100_ax_defconfig.bg2cd_dmp_nol2:CONFIG_CPU_PJ4=y arch/arm/configs/mv88de3100_ax_defconfig.bg2cd_dngle_256:CONFIG_CPU_PJ4=y arch/arm/configs/mv88de3100_ax_defconfig.bg2cd_dngle_nol2:CONFIG_CPU_PJ4=y arch/arm/configs/mv88de3100_ax_emmc_android_defconfig:CONFIG_CPU_PJ4=y arch/arm/configs/mv88de3100_ax_linux_defconfig:CONFIG_CPU_PJ4=y $ git grep CACHE_TAUROS3= arch/arm/configs/*mv88* arch/arm/configs/eureka_mv88de31xx_defconfig:CONFIG_CACHE_TAUROS3=y arch/arm/configs/mv88de3100_ax_android_defconfig:CONFIG_CACHE_TAUROS3=y arch/arm/configs/mv88de3100_ax_bg2a0_rdkdmp_dongle_defconfig:CONFIG_CACHE_TAUROS3=y arch/arm/configs/mv88de3100_ax_defconfig.bg2:CONFIG_CACHE_TAUROS3=y arch/arm/configs/mv88de3100_ax_defconfig.bg2cd_dmp:CONFIG_CACHE_TAUROS3=y arch/arm/configs/mv88de3100_ax_defconfig.bg2cd_dngle_256:CONFIG_CACHE_TAUROS3=y arch/arm/configs/mv88de3100_ax_emmc_android_defconfig:CONFIG_CACHE_TAUROS3=y arch/arm/configs/mv88de3100_ax_linux_defconfig:CONFIG_CACHE_TAUROS3=y $ git grep CACHE_PL310 arch/arm/configs/*mv88* arch/arm/configs/eureka_mv88de30xx_defconfig:CONFIG_CACHE_PL310=y $ git grep L2X arch/arm/configs/*mv88* arch/arm/configs/eureka_mv88de30xx_defconfig:CONFIG_CACHE_L2X0=y $ git grep MV88DE3100_BG= arch/arm/configs/*mv88* arch/arm/configs/eureka_mv88de30xx_defconfig:CONFIG_MV88DE3100_BG2_CD=y arch/arm/configs/eureka_mv88de31xx_defconfig:CONFIG_MV88DE3100_BG2_A0=y arch/arm/configs/mv88de3100_ax_android_defconfig:CONFIG_MV88DE3100_BG2_A0=y arch/arm/configs/mv88de3100_ax_bg2a0_rdkdmp_dongle_defconfig:CONFIG_MV88DE3100_BG2_A0=y arch/arm/configs/mv88de3100_ax_defconfig.bg2:CONFIG_MV88DE3100_BG2_A0=y arch/arm/configs/mv88de3100_ax_defconfig.bg2cd_dmp:CONFIG_MV88DE3100_BG2_A0=y arch/arm/configs/mv88de3100_ax_defconfig.bg2cd_dmp_nol2:CONFIG_MV88DE3100_BG2_A0=y arch/arm/configs/mv88de3100_ax_defconfig.bg2cd_dngle_256:CONFIG_MV88DE3100_BG2_A0=y arch/arm/configs/mv88de3100_ax_defconfig.bg2cd_dngle_nol2:CONFIG_MV88DE3100_BG2_A0=y arch/arm/configs/mv88de3100_ax_emmc_android_defconfig:CONFIG_MV88DE3100_BG2_A0=y arch/arm/configs/mv88de3100_ax_linux_defconfig:CONFIG_MV88DE3100_BG2_A0=y Evidently, the only defconfig that is for Cortex-A9 is eureka_mv88de30xx_defconfig, which is used on the Chromecast and has version MV88DE3100_BG2_CD (presumably renamed to product number de3005). LOCAL_TIMER is used exactly on those that have SMP support
Re: [PATCH v2] dmaengine: make dmatest less noisy
On Mon, Aug 19, 2013 at 1:37 AM, Andy Shevchenko andriy.shevche...@linux.intel.com wrote: On Mon, 2013-08-19 at 10:25 +0200, Linus Walleij wrote: Commit 95019c8c5 dmatest: gather test results in the linked list started to warning whenever we add results to a test thread. A warning for something completely normal? This is just cluttering my terminal. Move to debug prints. Cc: Andy Shevchenko andriy.shevche...@linux.intel.com Signed-off-by: Linus Walleij linus.wall...@linaro.org --- a/drivers/dma/dmatest.c +++ b/drivers/dma/dmatest.c @@ -406,7 +406,7 @@ static int thread_result_add(struct dmatest_info *info, list_add_tail(tr-node, r-results); mutex_unlock(info-results_lock); - pr_warn(%s\n, thread_result_get(r-name, tr)); + pr_debug(%s\n, thread_result_get(r-name, tr)); This is the idea behind original DMATEST module logic. As far as I understand we would like to have them as warnings in case when driver is compiled in and tests are run from the beginning. Though, I sent a correction patch that moves No error messages to debug level which, I think, makes sense. I don't know why Dan still keep silent on my last message in the discussion [1]. Applying them now, and yes I agree with your patch to take this back to the original implementation of not squawking on success. [1] http://www.spinics.net/lists/kernel/msg1581822.html -- Andy Shevchenko andriy.shevche...@linux.intel.com Intel Finland Oy -- 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/ -- 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] extcon: palmas: Modified the compatible type to *ti,palmas-usb-vid*
On Monday 19 August 2013 10:35 AM, Kishon Vijay Abraham I wrote: Hi, On Saturday 17 August 2013 03:51 AM, Stephen Warren wrote: On 08/16/2013 04:20 AM, Kishon Vijay Abraham I wrote: The Palmas device contains only a USB VID detector, so modified the compatible type to *ti,palmas-usb-vid*. diff --git a/Documentation/devicetree/bindings/extcon/extcon-palmas.txt b/Documentation/devicetree/bindings/extcon/extcon-palmas.txt PALMAS USB COMPARATOR Required Properties: - - compatible : Should be ti,palmas-usb or ti,twl6035-usb + - compatible : Should be ti,palmas-usb-vid. Has the old value been published in a release kernel? If so, it makes No. This was merged only in 3.11-rc1. So I think we should take this version? Chanwoo can you take this patch? Ah.. the old values will be part of 3.11 kernel. So should we retain the old values? -Kishon -- 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] dmaengine: make dmatest less noisy
On Mon, 2013-08-19 at 01:49 -0700, Dan Williams wrote: On Mon, Aug 19, 2013 at 1:37 AM, Andy Shevchenko andriy.shevche...@linux.intel.com wrote: On Mon, 2013-08-19 at 10:25 +0200, Linus Walleij wrote: Commit 95019c8c5 dmatest: gather test results in the linked list started to warning whenever we add results to a test thread. A warning for something completely normal? This is just cluttering my terminal. Move to debug prints. Cc: Andy Shevchenko andriy.shevche...@linux.intel.com Signed-off-by: Linus Walleij linus.wall...@linaro.org --- a/drivers/dma/dmatest.c +++ b/drivers/dma/dmatest.c @@ -406,7 +406,7 @@ static int thread_result_add(struct dmatest_info *info, list_add_tail(tr-node, r-results); mutex_unlock(info-results_lock); - pr_warn(%s\n, thread_result_get(r-name, tr)); + pr_debug(%s\n, thread_result_get(r-name, tr)); This is the idea behind original DMATEST module logic. As far as I understand we would like to have them as warnings in case when driver is compiled in and tests are run from the beginning. Though, I sent a correction patch that moves No error messages to debug level which, I think, makes sense. I don't know why Dan still keep silent on my last message in the discussion [1]. Applying them now, and yes I agree with your patch to take this back to the original implementation of not squawking on success. Thank you! -- Andy Shevchenko andriy.shevche...@linux.intel.com Intel Finland Oy -- 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/6] simplify platform_get_resource_byname/devm_ioremap_resource
devm_ioremap_resource often uses the result of a call to
platform_get_resource_byname as its last argument. devm_ioremap_resource
does appropriate error handling on this argument, so error handling can be
removed from the call to platform_get_resource_byname.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@@
expression pdev,res,n,e,e1;
expression ret != 0;
identifier l,f;
expression list es;
@@
(
res = f(...);
- if (res == NULL) { ... \(goto l;\|return ret;\) }
e = devm_ioremap_resource(e1, res);
|
- res = f(es);
... when != res
- if (res == NULL) { ... \(goto l;\|return ret;\) }
... when != res
+ res = f(es);
e = devm_ioremap_resource(e1, res);
)
// /smpl
In practice, f is always platform_get_resource_byname (or
platform_get_resource, which was handled by a previous patch series). And
the call to platform_get_resource_byname always immediately precedes the
call to devm_ioremap_resource.
--
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/6] usb: musb: dsps: simplify platform_get_resource_byname/devm_ioremap_resource
From: Julia Lawall julia.law...@lip6.fr
Remove unneeded error handling on the result of a call to
platform_get_resource_byname when the value is passed to devm_ioremap_resource.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression pdev,res,e,e1;
expression ret != 0;
identifier l;
@@
res = platform_get_resource_byname(...);
- if (res == NULL) { ... \(goto l;\|return ret;\) }
e = devm_ioremap_resource(e1, res);
// /smpl
Signed-off-by: Julia Lawall julia.law...@lip6.fr
---
drivers/usb/musb/musb_dsps.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 4ffbaac..f2f9710 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -357,9 +357,6 @@ static int dsps_musb_init(struct musb *musb)
u32 rev, val;
r = platform_get_resource_byname(parent, IORESOURCE_MEM, control);
- if (!r)
- return -EINVAL;
-
reg_base = devm_ioremap_resource(dev, r);
if (!musb-ctrl_base)
return -EINVAL;
--
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/6] mtd: fsmc_nand: simplify platform_get_resource_byname/devm_ioremap_resource
From: Julia Lawall julia.law...@lip6.fr
Remove unneeded error handling on the result of a call to
platform_get_resource_byname when the value is passed to devm_ioremap_resource.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression pdev,res,e,e1;
expression ret != 0;
identifier l;
@@
res = platform_get_resource_byname(...);
- if (res == NULL) { ... \(goto l;\|return ret;\) }
e = devm_ioremap_resource(e1, res);
// /smpl
Signed-off-by: Julia Lawall julia.law...@lip6.fr
---
drivers/mtd/nand/fsmc_nand.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/mtd/nand/fsmc_nand.c b/drivers/mtd/nand/fsmc_nand.c
index 2a3b1b9..3dc1a75 100644
--- a/drivers/mtd/nand/fsmc_nand.c
+++ b/drivers/mtd/nand/fsmc_nand.c
@@ -958,9 +958,6 @@ static int __init fsmc_nand_probe(struct platform_device
*pdev)
}
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, nand_data);
- if (!res)
- return -EINVAL;
-
host-data_va = devm_ioremap_resource(pdev-dev, res);
if (IS_ERR(host-data_va))
return PTR_ERR(host-data_va);
@@ -968,25 +965,16 @@ static int __init fsmc_nand_probe(struct platform_device
*pdev)
host-data_pa = (dma_addr_t)res-start;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, nand_addr);
- if (!res)
- return -EINVAL;
-
host-addr_va = devm_ioremap_resource(pdev-dev, res);
if (IS_ERR(host-addr_va))
return PTR_ERR(host-addr_va);
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, nand_cmd);
- if (!res)
- return -EINVAL;
-
host-cmd_va = devm_ioremap_resource(pdev-dev, res);
if (IS_ERR(host-cmd_va))
return PTR_ERR(host-cmd_va);
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, fsmc_regs);
- if (!res)
- return -EINVAL;
-
host-regs_va = devm_ioremap_resource(pdev-dev, res);
if (IS_ERR(host-regs_va))
return PTR_ERR(host-regs_va);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] regulator: ti-abb: simplify platform_get_resource_byname/devm_ioremap_resource
From: Julia Lawall julia.law...@lip6.fr
Remove unneeded error handling on the result of a call to
platform_get_resource_byname when the value is passed to devm_ioremap_resource.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression pdev,res,e,e1;
expression ret != 0;
identifier l;
@@
res = platform_get_resource_byname(...);
- if (res == NULL) { ... \(goto l;\|return ret;\) }
e = devm_ioremap_resource(e1, res);
// /smpl
Signed-off-by: Julia Lawall julia.law...@lip6.fr
---
drivers/regulator/ti-abb-regulator.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/regulator/ti-abb-regulator.c
b/drivers/regulator/ti-abb-regulator.c
index 3753ed0..d8e3e12 100644
--- a/drivers/regulator/ti-abb-regulator.c
+++ b/drivers/regulator/ti-abb-regulator.c
@@ -717,11 +717,6 @@ static int ti_abb_probe(struct platform_device *pdev)
/* Map ABB resources */
pname = base-address;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, pname);
- if (!res) {
- dev_err(dev, Missing '%s' IO resource\n, pname);
- ret = -ENODEV;
- goto err;
- }
abb-base = devm_ioremap_resource(dev, res);
if (IS_ERR(abb-base)) {
ret = PTR_ERR(abb-base);
@@ -770,11 +765,6 @@ static int ti_abb_probe(struct platform_device *pdev)
pname = ldo-address;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, pname);
- if (!res) {
- dev_dbg(dev, Missing '%s' IO resource\n, pname);
- ret = -ENODEV;
- goto skip_opt;
- }
abb-ldo_base = devm_ioremap_resource(dev, res);
if (IS_ERR(abb-ldo_base)) {
ret = PTR_ERR(abb-ldo_base);
--
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/6] MIPS: ath79: simplify platform_get_resource_byname/devm_ioremap_resource
From: Julia Lawall julia.law...@lip6.fr
Remove unneeded error handling on the result of a call to
platform_get_resource_byname when the value is passed to devm_ioremap_resource.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression pdev,res,e,e1;
expression ret != 0;
identifier l;
@@
res = platform_get_resource_byname(...);
- if (res == NULL) { ... \(goto l;\|return ret;\) }
e = devm_ioremap_resource(e1, res);
// /smpl
Signed-off-by: Julia Lawall julia.law...@lip6.fr
---
arch/mips/pci/pci-ar71xx.c |3 ---
arch/mips/pci/pci-ar724x.c |9 -
2 files changed, 12 deletions(-)
diff --git a/arch/mips/pci/pci-ar71xx.c b/arch/mips/pci/pci-ar71xx.c
index 18517dd..d471a26 100644
--- a/arch/mips/pci/pci-ar71xx.c
+++ b/arch/mips/pci/pci-ar71xx.c
@@ -363,9 +363,6 @@ static int ar71xx_pci_probe(struct platform_device *pdev)
spin_lock_init(apc-lock);
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, cfg_base);
- if (!res)
- return -EINVAL;
-
apc-cfg_base = devm_ioremap_resource(pdev-dev, res);
if (IS_ERR(apc-cfg_base))
return PTR_ERR(apc-cfg_base);
diff --git a/arch/mips/pci/pci-ar724x.c b/arch/mips/pci/pci-ar724x.c
index 65ec032..785b265 100644
--- a/arch/mips/pci/pci-ar724x.c
+++ b/arch/mips/pci/pci-ar724x.c
@@ -362,25 +362,16 @@ static int ar724x_pci_probe(struct platform_device *pdev)
return -ENOMEM;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, ctrl_base);
- if (!res)
- return -EINVAL;
-
apc-ctrl_base = devm_ioremap_resource(pdev-dev, res);
if (IS_ERR(apc-ctrl_base))
return PTR_ERR(apc-ctrl_base);
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, cfg_base);
- if (!res)
- return -EINVAL;
-
apc-devcfg_base = devm_ioremap_resource(pdev-dev, res);
if (IS_ERR(apc-devcfg_base))
return PTR_ERR(apc-devcfg_base);
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, crp_base);
- if (!res)
- return -EINVAL;
-
apc-crp_base = devm_ioremap_resource(pdev-dev, res);
if (IS_ERR(apc-crp_base))
return PTR_ERR(apc-crp_base);
--
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/6] watchdog: simplify platform_get_resource_byname/devm_ioremap_resource
From: Julia Lawall julia.law...@lip6.fr
Remove unneeded error handling on the result of a call to
platform_get_resource_byname when the value is passed to devm_ioremap_resource.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression pdev,res,e,e1;
expression ret != 0;
identifier l;
@@
res = platform_get_resource_byname(...);
- if (res == NULL) { ... \(goto l;\|return ret;\) }
e = devm_ioremap_resource(e1, res);
// /smpl
Signed-off-by: Julia Lawall julia.law...@lip6.fr
---
drivers/watchdog/ar7_wdt.c |5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/watchdog/ar7_wdt.c b/drivers/watchdog/ar7_wdt.c
index 2f3cc8f..b3709f9 100644
--- a/drivers/watchdog/ar7_wdt.c
+++ b/drivers/watchdog/ar7_wdt.c
@@ -280,11 +280,6 @@ static int ar7_wdt_probe(struct platform_device *pdev)
ar7_regs_wdt =
platform_get_resource_byname(pdev, IORESOURCE_MEM, regs);
- if (!ar7_regs_wdt) {
- pr_err(could not get registers resource\n);
- return -ENODEV;
- }
-
ar7_wdt = devm_ioremap_resource(pdev-dev, ar7_regs_wdt);
if (IS_ERR(ar7_wdt))
return PTR_ERR(ar7_wdt);
--
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/6] ASoC: omap: simplify platform_get_resource_byname/devm_ioremap_resource
From: Julia Lawall julia.law...@lip6.fr
Remove unneeded error handling on the result of a call to
platform_get_resource_byname when the value is passed to devm_ioremap_resource.
In the case of omap-dmic.c, the error-handling code of
devm_ioremap_resource is also corrected to include releasing the clock.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression pdev,res,e,e1;
expression ret != 0;
identifier l;
@@
res = platform_get_resource_byname(...);
- if (res == NULL) { ... \(goto l;\|return ret;\) }
e = devm_ioremap_resource(e1, res);
// /smpl
Signed-off-by: Julia Lawall julia.law...@lip6.fr
---
sound/soc/omap/omap-dmic.c |9 +++--
sound/soc/omap/omap-mcpdm.c |3 ---
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/omap/omap-dmic.c
index 4db1f8e..12e566b 100644
--- a/sound/soc/omap/omap-dmic.c
+++ b/sound/soc/omap/omap-dmic.c
@@ -480,15 +480,12 @@ static int asoc_dmic_probe(struct platform_device *pdev)
dmic-dma_data.filter_data = up_link;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, mpu);
- if (!res) {
- dev_err(dmic-dev, invalid memory resource\n);
- ret = -ENODEV;
+ dmic-io_base = devm_ioremap_resource(pdev-dev, res);
+ if (IS_ERR(dmic-io_base)) {
+ ret = PTR_ERR(dmic-io_base);
goto err_put_clk;
}
- dmic-io_base = devm_ioremap_resource(pdev-dev, res);
- if (IS_ERR(dmic-io_base))
- return PTR_ERR(dmic-io_base);
ret = snd_soc_register_component(pdev-dev, omap_dmic_component,
omap_dmic_dai, 1);
diff --git a/sound/soc/omap/omap-mcpdm.c b/sound/soc/omap/omap-mcpdm.c
index a49dc52..90d2a7c 100644
--- a/sound/soc/omap/omap-mcpdm.c
+++ b/sound/soc/omap/omap-mcpdm.c
@@ -480,9 +480,6 @@ static int asoc_mcpdm_probe(struct platform_device *pdev)
mcpdm-dma_data[1].filter_data = up_link;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, mpu);
- if (res == NULL)
- return -ENOMEM;
-
mcpdm-io_base = devm_ioremap_resource(pdev-dev, res);
if (IS_ERR(mcpdm-io_base))
return PTR_ERR(mcpdm-io_base);
--
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: dmaengine: make dma_channel_rebalance() NUMA aware
Le 19/08/2013 10:19, Dan Williams a écrit :
* @cap: capability to match
- * @n: nth channel desired
+ * @cpu: cpu index which the channel should be close to
*
- * Defaults to returning the channel with the desired capability and the
- * lowest reference count when 'n' cannot be satisfied. Must be called
- * under dma_list_mutex.
+ * If some channels are close to the given cpu, the one with the lowest
+ * reference count is returned. Otherwise, cpu is ignored and only the
+ * reference count is taken into account.
I think we can drop these comments and the distinction, see below.
I understand that we can remove the cpu==-1 case, but I don't see why we
would remove the 3 last lines above. The code still looks for a
NUMA-local channels first.
Here's an updated patch with all your comments applied, except the
removal of these 3 comment lines.
Brice
dmaengine: make dma_channel_rebalance() NUMA aware
dma_channel_rebalance() currently distributes channels by processor ID.
These IDs often change with the BIOS, and the order isn't related to
the DMA channel list (related to PCI bus ids).
* On my SuperMicro dual E5 machine, first socket has processor IDs [0-7]
(and [16-23] for hyperthreads), second socket has [8-15]+[24-31]
= channels are properly allocated to local CPUs.
* On Dells R720 with same processors, first socket has even processor IDs,
second socket has odd numbers
= half the processors get channels on the remote socket, causing
cross-NUMA traffic and lower DMA performance.
Change nth_chan() to return the channel with min table_count and in the
NUMA node of the given CPU, if any. If none, the (non-local) channel with
min table_count is returned. nth_chan() is therefore renamed into min_chan()
since we don't iterate until the nth channel anymore. In practice, the
behavior is the same because first channels are taken first and are then
ignored because they got an additional reference.
The new code has a slightly higher complexity since we always scan the
entire list of channels for finding the minimal table_count (instead
of stopping after N chans), and because we check whether the CPU is in the
DMA device locality mask. Overall we still have time complexity =
number of chans x number of processors. This rebalance is rarely used,
so this won't hurt.
On the above SuperMicro machine, channels are still allocated the same.
On the Dells, there are no locality issue anymore (MEMCPY channel X goes
to processor X and to its hyperthread sibling).
Signed-off-by: Brice Goglin brice.gog...@inria.fr
---
drivers/dma/dmaengine.c | 64 +++-
1 file changed, 37 insertions(+), 27 deletions(-)
Index: linux-3.11-rc3/drivers/dma/dmaengine.c
===
--- linux-3.11-rc3.orig/drivers/dma/dmaengine.c 2013-07-29 05:53:33.0
+0200
+++ linux-3.11-rc3/drivers/dma/dmaengine.c 2013-08-19 10:31:10.600721807
+0200
@@ -376,20 +376,30 @@ void dma_issue_pending_all(void)
EXPORT_SYMBOL(dma_issue_pending_all);
/**
- * nth_chan - returns the nth channel of the given capability
+ * dma_chan_is_local - returns true if the channel is in the same numa-node as
the cpu
+ */
+static bool dma_chan_is_local(struct dma_chan *chan, int cpu)
+{
+ int node = dev_to_node(chan-device-dev);
+ return node == -1 || cpumask_test_cpu(cpu, cpumask_of_node(node));
+}
+
+/**
+ * min_chan - returns the channel with min count and in the same numa-node as
the cpu
* @cap: capability to match
- * @n: nth channel desired
+ * @cpu: cpu index which the channel should be close to
*
- * Defaults to returning the channel with the desired capability and the
- * lowest reference count when 'n' cannot be satisfied. Must be called
- * under dma_list_mutex.
+ * If some channels are close to the given cpu, the one with the lowest
+ * reference count is returned. Otherwise, cpu is ignored and only the
+ * reference count is taken into account.
+ * Must be called under dma_list_mutex.
*/
-static struct dma_chan *nth_chan(enum dma_transaction_type cap, int n)
+static struct dma_chan *min_chan(enum dma_transaction_type cap, int cpu)
{
struct dma_device *device;
struct dma_chan *chan;
- struct dma_chan *ret = NULL;
struct dma_chan *min = NULL;
+ struct dma_chan *localmin = NULL;
list_for_each_entry(device, dma_device_list, global_node) {
if (!dma_has_cap(cap, device-cap_mask) ||
@@ -398,27 +408,22 @@ static struct dma_chan *nth_chan(enum dm
list_for_each_entry(chan, device-channels, device_node) {
if (!chan-client_count)
continue;
- if (!min)
- min = chan;
- else if (chan-table_count min-table_count)
+ if (!min || chan-table_count min-table_count)
Re: [PATCH 1/2] ARC: gdbserver breakage in Big-Endian configuration #1
Hi Greg,
I'd posted these patches for stable backport. Do I need to do anything more to
get them included.
https://patchwork.kernel.org/patch/2841153/ [1/2] ARC: gdbserver breakage in
Big-Endian configuration #1https://patchwork.kernel.org/patch/2841153/]
https://patchwork.kernel.org/patch/2841158/ [2/2] ARC: gdbserver breakage in
Big-Endian configuration #2https://patchwork.kernel.org/patch/2841158/
Thx,
-Vineet
On 08/08/2013 07:23 PM, Vineet Gupta wrote:
Exception handling keeps additional state (whether exception was Trap
and if it was due to a breakpoint) in pt_regs-event, a bitfield member
unsigned long orig_r8:16, event:16;
A bitfield esentially has an offset and a length. What I wasn't
aware of was that, bitfields in a union loose the offset attribute
and all of them are laid out at offset 0.
This obviously means that both @event and @orig_r8 will be incorrectly
referenced to at same 0 offset by C generated code which is
certainly wrong, not because both members are accessed, but because asm
code updates it at different address.
In Little Endian config, @event is at offset 0 and @orig_r8 (not
actively used at all) clashing with it is OK. However in Big Endian
config,
ST 0x_, [addr]
writes 0x to @event (offset 2 in memory) while C code references
it from 0.
Needless to say, this causes ptrace machinery to not detect the breakpoint
scenario (and incorrect stop_pc returned to gdbserver).
--8---
Thi issue is already fixed in mainline 3.11 kernel as part of commit:
502a0c775c7f0a ARC: pt_regs update #5
However that patch has lot more changes than I would like backporting,
hence this seperate change.
--8---
Reported-by: Noam Camus no...@ezchip.commailto:no...@ezchip.com
Cc: sta...@vger.kernel.orgmailto:sta...@vger.kernel.org # [3.9 and 3.10
only]
Tested-by: Anton Kolesov akole...@synopsys.commailto:akole...@synopsys.com
Signed-off-by: Vineet Gupta vgu...@synopsys.commailto:vgu...@synopsys.com
---
arch/arc/include/asm/ptrace.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arc/include/asm/ptrace.h b/arch/arc/include/asm/ptrace.h
index 6179de7..2046a89 100644
--- a/arch/arc/include/asm/ptrace.h
+++ b/arch/arc/include/asm/ptrace.h
@@ -52,12 +52,14 @@ struct pt_regs {
/*to distinguish bet excp, syscall, irq */
union {
+ struct {
#ifdef CONFIG_CPU_BIG_ENDIAN
/* so that assembly code is same for LE/BE */
unsigned long orig_r8:16, event:16;
#else
unsigned long event:16, orig_r8:16;
#endif
+ };
long orig_r8_word;
};
};
--
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 5/6] regulator: ti-abb: simplify platform_get_resource_byname/devm_ioremap_resource
Am 19.08.2013 10:51, schrieb Julia Lawall:
From: Julia Lawall julia.law...@lip6.fr
Remove unneeded error handling on the result of a call to
platform_get_resource_byname when the value is passed to
devm_ioremap_resource.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression pdev,res,e,e1;
expression ret != 0;
identifier l;
@@
res = platform_get_resource_byname(...);
- if (res == NULL) { ... \(goto l;\|return ret;\) }
e = devm_ioremap_resource(e1, res);
// /smpl
Signed-off-by: Julia Lawall julia.law...@lip6.fr
---
drivers/regulator/ti-abb-regulator.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/regulator/ti-abb-regulator.c
b/drivers/regulator/ti-abb-regulator.c
index 3753ed0..d8e3e12 100644
--- a/drivers/regulator/ti-abb-regulator.c
+++ b/drivers/regulator/ti-abb-regulator.c
@@ -717,11 +717,6 @@ static int ti_abb_probe(struct platform_device *pdev)
/* Map ABB resources */
pname = base-address;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, pname);
- if (!res) {
- dev_err(dev, Missing '%s' IO resource\n, pname);
- ret = -ENODEV;
- goto err;
- }
abb-base = devm_ioremap_resource(dev, res);
if (IS_ERR(abb-base)) {
ret = PTR_ERR(abb-base);
is pname used by anything else ? (also below)
re,
wh
@@ -770,11 +765,6 @@ static int ti_abb_probe(struct platform_device *pdev)
pname = ldo-address;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, pname);
- if (!res) {
- dev_dbg(dev, Missing '%s' IO resource\n, pname);
- ret = -ENODEV;
- goto skip_opt;
- }
abb-ldo_base = devm_ioremap_resource(dev, res);
if (IS_ERR(abb-ldo_base)) {
ret = PTR_ERR(abb-ldo_base);
--
To unsubscribe from this list: send the line unsubscribe kernel-janitors 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 5/6] regulator: ti-abb: simplify platform_get_resource_byname/devm_ioremap_resource
On Mon, 19 Aug 2013, walter harms wrote:
Am 19.08.2013 10:51, schrieb Julia Lawall:
From: Julia Lawall julia.law...@lip6.fr
Remove unneeded error handling on the result of a call to
platform_get_resource_byname when the value is passed to
devm_ioremap_resource.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression pdev,res,e,e1;
expression ret != 0;
identifier l;
@@
res = platform_get_resource_byname(...);
- if (res == NULL) { ... \(goto l;\|return ret;\) }
e = devm_ioremap_resource(e1, res);
// /smpl
Signed-off-by: Julia Lawall julia.law...@lip6.fr
---
drivers/regulator/ti-abb-regulator.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/regulator/ti-abb-regulator.c
b/drivers/regulator/ti-abb-regulator.c
index 3753ed0..d8e3e12 100644
--- a/drivers/regulator/ti-abb-regulator.c
+++ b/drivers/regulator/ti-abb-regulator.c
@@ -717,11 +717,6 @@ static int ti_abb_probe(struct platform_device *pdev)
/* Map ABB resources */
pname = base-address;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, pname);
- if (!res) {
- dev_err(dev, Missing '%s' IO resource\n, pname);
- ret = -ENODEV;
- goto err;
- }
abb-base = devm_ioremap_resource(dev, res);
if (IS_ERR(abb-base)) {
ret = PTR_ERR(abb-base);
is pname used by anything else ? (also below)
I'll check. Thanks for the feedback.
julia
re,
wh
@@ -770,11 +765,6 @@ static int ti_abb_probe(struct platform_device *pdev)
pname = ldo-address;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, pname);
- if (!res) {
- dev_dbg(dev, Missing '%s' IO resource\n, pname);
- ret = -ENODEV;
- goto skip_opt;
- }
abb-ldo_base = devm_ioremap_resource(dev, res);
if (IS_ERR(abb-ldo_base)) {
ret = PTR_ERR(abb-ldo_base);
--
To unsubscribe from this list: send the line unsubscribe kernel-janitors
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 kernel-janitors 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 v1 1/2] perf: add attr-mmap2 attribute to an event
On Thu, Aug 15, 2013 at 12:26 PM, Peter Zijlstra pet...@infradead.org wrote:
On Tue, Aug 13, 2013 at 01:55:56PM +0200, Stephane Eranian wrote:
@@ -638,6 +639,25 @@ enum perf_event_type {
*/
PERF_RECORD_SAMPLE = 9,
+ /*
+ * The MMAP2 records are an augmented version of MMAP, they add
+ * maj, min, ino numbers to be used to uniquely identify each mapping
+ *
+ * struct {
+ * struct perf_event_headerheader;
+ *
+ * u32 pid, tid;
+ * u64 addr;
+ * u64 len;
+ * u64 pgoff;
+ * u32 maj;
+ * u32 min;
+ * u64 ino;
+ * charfilename[];
Did you forget the sample_id stuff?
struct sample_idsample_id;
Ok, will add that and the i_generation field.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] GFS2: Check for glock already held in gfs2_getxattr
Since the introduction of atomic_open, gfs2_getxattr can be
called with the glock already held, so we need to allow for
this.
Signed-off-by: Steven Whitehouse swhit...@redhat.com
Reported-by: David Teigland teigl...@redhat.com
Tested-by: David Teigland teigl...@redhat.com
diff --git a/fs/gfs2/inode.c b/fs/gfs2/inode.c
index a01b8fd..64915ee 100644
--- a/fs/gfs2/inode.c
+++ b/fs/gfs2/inode.c
@@ -1750,6 +1750,10 @@ static ssize_t gfs2_getxattr(struct dentry *dentry,
const char *name,
struct gfs2_holder gh;
int ret;
+ /* For selinux during lookup */
+ if (gfs2_glock_is_locked_by_me(ip-i_gl))
+ return generic_getxattr(dentry, name, data, size);
+
gfs2_holder_init(ip-i_gl, LM_ST_SHARED, LM_FLAG_ANY, gh);
ret = gfs2_glock_nq(gh);
if (ret == 0) {
--
1.7.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/5] GFS2: alloc_workqueue() doesn't return an ERR_PTR
From: Dan Carpenter dan.carpen...@oracle.com
alloc_workqueue() returns a NULL on error, it doesn't return an ERR_PTR.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Steven Whitehouse swhit...@redhat.com
diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c
index 9435384..544a809 100644
--- a/fs/gfs2/glock.c
+++ b/fs/gfs2/glock.c
@@ -1838,14 +1838,14 @@ int __init gfs2_glock_init(void)
glock_workqueue = alloc_workqueue(glock_workqueue, WQ_MEM_RECLAIM |
WQ_HIGHPRI | WQ_FREEZABLE, 0);
- if (IS_ERR(glock_workqueue))
- return PTR_ERR(glock_workqueue);
+ if (!glock_workqueue)
+ return -ENOMEM;
gfs2_delete_workqueue = alloc_workqueue(delete_workqueue,
WQ_MEM_RECLAIM | WQ_FREEZABLE,
0);
- if (IS_ERR(gfs2_delete_workqueue)) {
+ if (!gfs2_delete_workqueue) {
destroy_workqueue(glock_workqueue);
- return PTR_ERR(gfs2_delete_workqueue);
+ return -ENOMEM;
}
register_shrinker(glock_shrinker);
--
1.7.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: [Help Test] kdump, x86, acpi: Reproduce CPU0 SMI corruption issue after unsetting BSP flag
(2013/08/19 11:59), Eric W. Biederman wrote: Sorry Eric, I'm not clear to what you mean by ``short one core''... Which are you suggesting? Disabling BSP if crash happens on AP is reasonable? Or restricting cpus to a single one only just as the current kdump configuration is reasonable? I am suggesting we start every cpu except the BSP from the AP we started on. N-1 cpus seems like a good tradeoff between performance and reliability for those who need it. Eric Thanks. I'm now clear. Well, I'll post a version 2 patch after upgrading it for current upstream kernel. But it would be next week or later. -- Thanks. HATAYAMA, Daisuke -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] GFS2: Fix typo in gfs2_create_inode()
PTR_RET should be PTR_ERR
Reported-by: Sachin Kamat sachin.ka...@linaro.org
Cc: Rusty Russell ru...@rustcorp.com.au
Signed-off-by: Steven Whitehouse swhit...@redhat.com
diff --git a/fs/gfs2/inode.c b/fs/gfs2/inode.c
index bbb2715..a01b8fd 100644
--- a/fs/gfs2/inode.c
+++ b/fs/gfs2/inode.c
@@ -594,7 +594,7 @@ static int gfs2_create_inode(struct inode *dir, struct
dentry *dentry,
}
gfs2_glock_dq_uninit(ghs);
if (IS_ERR(d))
- return PTR_RET(d);
+ return PTR_ERR(d);
return error;
} else if (error != -ENOENT) {
goto fail_gunlock;
--
1.7.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 3/5] GFS2: don't overrun reserved revokes
From: Benjamin Marzinski bmarz...@redhat.com
When run during fsync, a gfs2_log_flush could happen between the
time when gfs2_ail_flush checked the number of blocks to revoke,
and when it actually started the transaction to do those revokes.
This occassionally caused it to need more revokes than it reserved,
causing gfs2 to crash.
Instead of just reserving enough revokes to handle the blocks that
currently need them, this patch makes gfs2_ail_flush reserve the
maximum number of revokes it can, without increasing the total number
of reserved log blocks. This patch also passes the number of reserved
revokes to __gfs2_ail_flush() so that it doesn't go over its limit
and cause a crash like we're seeing. Non-fsync calls to __gfs2_ail_flush
will still cause a BUG() necessary revokes are skipped.
Signed-off-by: Benjamin Marzinski bmarz...@redhat.com
Signed-off-by: Steven Whitehouse swhit...@redhat.com
diff --git a/fs/gfs2/glops.c b/fs/gfs2/glops.c
index 5f2e522..e2e0a90 100644
--- a/fs/gfs2/glops.c
+++ b/fs/gfs2/glops.c
@@ -47,7 +47,8 @@ static void gfs2_ail_error(struct gfs2_glock *gl, const
struct buffer_head *bh)
* None of the buffers should be dirty, locked, or pinned.
*/
-static void __gfs2_ail_flush(struct gfs2_glock *gl, bool fsync)
+static void __gfs2_ail_flush(struct gfs2_glock *gl, bool fsync,
+unsigned int nr_revokes)
{
struct gfs2_sbd *sdp = gl-gl_sbd;
struct list_head *head = gl-gl_ail_list;
@@ -57,7 +58,9 @@ static void __gfs2_ail_flush(struct gfs2_glock *gl, bool
fsync)
gfs2_log_lock(sdp);
spin_lock(sdp-sd_ail_lock);
- list_for_each_entry_safe(bd, tmp, head, bd_ail_gl_list) {
+ list_for_each_entry_safe_reverse(bd, tmp, head, bd_ail_gl_list) {
+ if (nr_revokes == 0)
+ break;
bh = bd-bd_bh;
if (bh-b_state b_state) {
if (fsync)
@@ -65,6 +68,7 @@ static void __gfs2_ail_flush(struct gfs2_glock *gl, bool
fsync)
gfs2_ail_error(gl, bh);
}
gfs2_trans_add_revoke(sdp, bd);
+ nr_revokes--;
}
GLOCK_BUG_ON(gl, !fsync atomic_read(gl-gl_ail_count));
spin_unlock(sdp-sd_ail_lock);
@@ -91,7 +95,7 @@ static void gfs2_ail_empty_gl(struct gfs2_glock *gl)
WARN_ON_ONCE(current-journal_info);
current-journal_info = tr;
- __gfs2_ail_flush(gl, 0);
+ __gfs2_ail_flush(gl, 0, tr.tr_revokes);
gfs2_trans_end(sdp);
gfs2_log_flush(sdp, NULL);
@@ -101,15 +105,19 @@ void gfs2_ail_flush(struct gfs2_glock *gl, bool fsync)
{
struct gfs2_sbd *sdp = gl-gl_sbd;
unsigned int revokes = atomic_read(gl-gl_ail_count);
+ unsigned int max_revokes = (sdp-sd_sb.sb_bsize - sizeof(struct
gfs2_log_descriptor)) / sizeof(u64);
int ret;
if (!revokes)
return;
- ret = gfs2_trans_begin(sdp, 0, revokes);
+ while (revokes max_revokes)
+ max_revokes += (sdp-sd_sb.sb_bsize - sizeof(struct
gfs2_meta_header)) / sizeof(u64);
+
+ ret = gfs2_trans_begin(sdp, 0, max_revokes);
if (ret)
return;
- __gfs2_ail_flush(gl, fsync);
+ __gfs2_ail_flush(gl, fsync, max_revokes);
gfs2_trans_end(sdp);
gfs2_log_flush(sdp, NULL);
}
--
1.7.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/5] GFS2: WQ_NON_REENTRANT is meaningless and going away
From: Tejun Heo t...@kernel.org dbf2576e37 (workqueue: make all workqueues non-reentrant) made WQ_NON_REENTRANT no-op and the flag is going away. Remove its usages. This patch doesn't introduce any behavior changes. Signed-off-by: Tejun Heo t...@kernel.org Signed-off-by: Steven Whitehouse swhit...@redhat.com Cc: cluster-de...@redhat.com diff --git a/fs/gfs2/main.c b/fs/gfs2/main.c index e04d0e0..7b0f504 100644 --- a/fs/gfs2/main.c +++ b/fs/gfs2/main.c @@ -155,7 +155,7 @@ static int __init init_gfs2_fs(void) goto fail_wq; gfs2_control_wq = alloc_workqueue(gfs2_control, - WQ_NON_REENTRANT | WQ_UNBOUND | WQ_FREEZABLE, 0); + WQ_UNBOUND | WQ_FREEZABLE, 0); if (!gfs2_control_wq) goto fail_recovery; -- 1.7.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/
GFS2: Pre-pull patch posting (fixes)
Hi, Out of these fives patches, the one for ensuring that the number of revokes is not exceeded, and the one for checking the glock is not already held in gfs2_getxattr are the two most important. The latter can be triggered by selinux. The other three patches are very small and fix mostly fairly trivial issues, Steve. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] perf x86: Make intel_pmu_enable_all to enable only active events
On Thu, Aug 15, 2013 at 3:53 PM, Andi Kleen a...@firstfloor.org wrote: I think its a NOP; this is the global ctrl register but intel_pmu_disable_event() writes PERFEVTSELx.EN = 0, so even if you enable it in the global mask, the event should still be disabled. Yes the hardware ANDs the various enable bits in the different registers. Andi is correct. There is a logical AND between GLOBAL_CTRL and the individual PERFEVTCTL.EN bits. If the EN bit is zero, then the counter does not count. That also applies to fixed counters. -- 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] um: ubd: Add REQ_FLUSH suppport
On Sun, Aug 18, 2013 at 12:09:34AM +0200, Richard Weinberger wrote: UML's block device driver does not support write barriers, to support this this patch adds REQ_FLUSH suppport. Every time the block layer sends a REQ_FLUSH we fsync() now our backing file to guarantee data consistency. This fixes the sync problem I saw before. So: Tested-by: Richard W.M. Jones rjo...@redhat.com Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- 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 tip/core/rcu 01/11] rcu: Expedite grace periods during suspend/resume
On Sun, Aug 18, 2013 at 05:29:10PM -0700, Paul E. McKenney wrote: I would guess that once we have a few more subsystems that want RCU to temporarily expedite its grace periods, we will have enough information and experience to do something a bit more general. In the meantime, I am opting for something simple. ;-) Aah, the empirical approach! Very wise, master Jedi :-) -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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] staging: dgrp: add __init/__exit macros
add __init/__exit macros to related init/cleanup functions.
Signed-off-by: navin patidar nav...@cdac.in
---
drivers/staging/dgrp/dgrp_driver.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/dgrp/dgrp_driver.c
b/drivers/staging/dgrp/dgrp_driver.c
index e456dc6c..08eedf0 100644
--- a/drivers/staging/dgrp/dgrp_driver.c
+++ b/drivers/staging/dgrp/dgrp_driver.c
@@ -52,19 +52,12 @@ MODULE_PARM_DESC(register_prdevices, Turn on/off
registering transparent print
module_param_named(pollrate, dgrp_poll_tick, int, 0644);
MODULE_PARM_DESC(pollrate, Poll interval in ms);
-/* Driver load/unload functions */
-static int dgrp_init_module(void);
-static void dgrp_cleanup_module(void);
-
-module_init(dgrp_init_module);
-module_exit(dgrp_cleanup_module);
-
/*
* init_module()
*
* Module load. This is where it all starts.
*/
-static int dgrp_init_module(void)
+static int __init dgrp_init_module(void)
{
int ret;
@@ -89,7 +82,7 @@ static int dgrp_init_module(void)
/*
* Module unload. This is where it all ends.
*/
-static void dgrp_cleanup_module(void)
+static void __exit dgrp_cleanup_module(void)
{
struct nd_struct *nd, *next;
@@ -108,3 +101,6 @@ static void dgrp_cleanup_module(void)
kfree(nd);
}
}
+
+module_init(dgrp_init_module);
+module_exit(dgrp_cleanup_module);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/35] i2c: use dev_get_platdata()
Now it's convincing, thanks! signature.asc Description: Digital signature
GFS2: Pull request (fixes)
Hi, Please consider pulling the following changes, Steve. - Out of these five patches, the one for ensuring that the number of revokes is not exceeded, and the one for checking the glock is not already held in gfs2_getxattr are the two most important. The latter can be triggered by selinux. The other three patches are very small and fix mostly fairly trivial issues. -- The following changes since commit 47188d39b5deeebf41f87a02af1b3935866364cf: Merge tag 'ext4_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 (2013-07-14 21:47:51 -0700) are available in the git repository at: https://git.kernel.org/cgit/linux/kernel/git/steve/gfs2-3.0-fixes.git master Benjamin Marzinski (1): GFS2: don't overrun reserved revokes Dan Carpenter (1): GFS2: alloc_workqueue() doesn't return an ERR_PTR Steven Whitehouse (2): GFS2: Fix typo in gfs2_create_inode() GFS2: Check for glock already held in gfs2_getxattr Tejun Heo (1): GFS2: WQ_NON_REENTRANT is meaningless and going away fs/gfs2/glock.c |8 fs/gfs2/glops.c | 18 +- fs/gfs2/inode.c |6 +- fs/gfs2/main.c |2 +- 4 files changed, 23 insertions(+), 11 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
GFS2: Pull request (fixes)
Oops, forgot to sign this when I sent it first, so here is a signed copy of it. Hi, Please consider pulling the following changes, Steve. - Out of these five patches, the one for ensuring that the number of revokes is not exceeded, and the one for checking the glock is not already held in gfs2_getxattr are the two most important. The latter can be triggered by selinux. The other three patches are very small and fix mostly fairly trivial issues. -- The following changes since commit 47188d39b5deeebf41f87a02af1b3935866364cf: Merge tag 'ext4_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 (2013-07-14 21:47:51 -0700) are available in the git repository at: https://git.kernel.org/cgit/linux/kernel/git/steve/gfs2-3.0-fixes.git master Benjamin Marzinski (1): GFS2: don't overrun reserved revokes Dan Carpenter (1): GFS2: alloc_workqueue() doesn't return an ERR_PTR Steven Whitehouse (2): GFS2: Fix typo in gfs2_create_inode() GFS2: Check for glock already held in gfs2_getxattr Tejun Heo (1): GFS2: WQ_NON_REENTRANT is meaningless and going away fs/gfs2/glock.c |8 fs/gfs2/glops.c | 18 +- fs/gfs2/inode.c |6 +- fs/gfs2/main.c |2 +- 4 files changed, 23 insertions(+), 11 deletions(-) signature.asc Description: This is a digitally signed message part
Re: [PATCH v2] extcon: palmas: Modified the compatible type to *ti,palmas-usb-vid*
On 08/19/2013 05:47 PM, Kishon Vijay Abraham I wrote: On Monday 19 August 2013 10:35 AM, Kishon Vijay Abraham I wrote: Hi, On Saturday 17 August 2013 03:51 AM, Stephen Warren wrote: On 08/16/2013 04:20 AM, Kishon Vijay Abraham I wrote: The Palmas device contains only a USB VID detector, so modified the compatible type to *ti,palmas-usb-vid*. diff --git a/Documentation/devicetree/bindings/extcon/extcon-palmas.txt b/Documentation/devicetree/bindings/extcon/extcon-palmas.txt PALMAS USB COMPARATOR Required Properties: - - compatible : Should be ti,palmas-usb or ti,twl6035-usb + - compatible : Should be ti,palmas-usb-vid. Has the old value been published in a release kernel? If so, it makes No. This was merged only in 3.11-rc1. So I think we should take this version? Chanwoo can you take this patch? Ah.. the old values will be part of 3.11 kernel. So should we retain the old values? What is the meaning of old value? previous value related to extcon-twl.txt? The extcon-twl.txt was included in 3.11 kernel and extcon-palmas.txt will be inclued in 3.12 kernel through char-misc repo of GregKH. Thanks, Chanwoo Choi -- 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] extcon: palmas: Modified the compatible type to *ti,palmas-usb-vid*
On Monday 19 August 2013 02:54 PM, Chanwoo Choi wrote: On 08/19/2013 05:47 PM, Kishon Vijay Abraham I wrote: On Monday 19 August 2013 10:35 AM, Kishon Vijay Abraham I wrote: Hi, On Saturday 17 August 2013 03:51 AM, Stephen Warren wrote: On 08/16/2013 04:20 AM, Kishon Vijay Abraham I wrote: The Palmas device contains only a USB VID detector, so modified the compatible type to *ti,palmas-usb-vid*. diff --git a/Documentation/devicetree/bindings/extcon/extcon-palmas.txt b/Documentation/devicetree/bindings/extcon/extcon-palmas.txt PALMAS USB COMPARATOR Required Properties: - - compatible : Should be ti,palmas-usb or ti,twl6035-usb + - compatible : Should be ti,palmas-usb-vid. Has the old value been published in a release kernel? If so, it makes No. This was merged only in 3.11-rc1. So I think we should take this version? Chanwoo can you take this patch? Ah.. the old values will be part of 3.11 kernel. So should we retain the old values? What is the meaning of old value? previous value related to extcon-twl.txt? We were discussing on whether to have ti,palmas-usb or ti,twl6035-usb in compatible value in addition to ti,palmas-usb-vid. Stephen wanted the old values (ti,palmas-usb or ti,twl6035-usb) if it has been published in a release kernel. The extcon-twl.txt was included in 3.11 kernel Right. Since it's part of 3.11 kernel, I think we should retain the old compatible values. Thanks Kishon -- 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: dmaengine: make dma_channel_rebalance() NUMA aware
On Mon, Aug 19, 2013 at 1:54 AM, Brice Goglin brice.gog...@inria.fr wrote: Le 19/08/2013 10:19, Dan Williams a écrit : * @cap: capability to match - * @n: nth channel desired + * @cpu: cpu index which the channel should be close to * - * Defaults to returning the channel with the desired capability and the - * lowest reference count when 'n' cannot be satisfied. Must be called - * under dma_list_mutex. + * If some channels are close to the given cpu, the one with the lowest + * reference count is returned. Otherwise, cpu is ignored and only the + * reference count is taken into account. I think we can drop these comments and the distinction, see below. I understand that we can remove the cpu==-1 case, but I don't see why we would remove the 3 last lines above. The code still looks for a NUMA-local channels first. Ah yes, it still handles the none local case. Here's an updated patch with all your comments applied, except the removal of these 3 comment lines. Thanks! -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmaengine: make dma_channel_rebalance() NUMA aware
+ for_each_online_cpu(cpu)
+ per_cpu_ptr(channel_table[cap], cpu)-chan
+= min_chan(cap, cpu);
...this line-wrap strikes me weird. I think we can afford a few extra
lines and do:
for_each_online_cpu(cpu) {
chan = min_chan(cap, cpu);
per_cpu_ptr(channel_table[cap], cpu)-chan = chan;
}
--
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/
[GIT PULL] timer fixes
Linus,
Please pull the latest timers-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
timers-urgent-for-linus
HEAD: ae920eb24277e4a174a3ca575ce42b98b18a6748 Merge branch
'fortglx/3.11/time' of git://git.linaro.org/people/jstultz/linux into
timers/urgent
Three small fixlets.
Thanks,
Ingo
--
Baruch Siach (1):
sched_clock: Fix integer overflow
Li Zhong (1):
nohz: fix compile warning in tick_nohz_init()
Steven Rostedt (1):
nohz: Do not warn about unstable tsc unless user uses nohz_full
kernel/time/sched_clock.c | 2 +-
kernel/time/tick-sched.c | 5 ++---
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
index a326f27..0b479a6 100644
--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -121,7 +121,7 @@ void __init setup_sched_clock(u32 (*read)(void), int bits,
unsigned long rate)
BUG_ON(bits 32);
WARN_ON(!irqs_disabled());
read_sched_clock = read;
- sched_clock_mask = (1 bits) - 1;
+ sched_clock_mask = (1ULL bits) - 1;
cd.rate = rate;
/* calculate the mult/shift to convert counter ticks to ns. */
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index e80183f..9563c74 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -182,7 +182,8 @@ static bool can_stop_full_tick(void)
* Don't allow the user to think they can get
* full NO_HZ with this machine.
*/
- WARN_ONCE(1, NO_HZ FULL will not work with unstable sched
clock);
+ WARN_ONCE(have_nohz_full_mask,
+ NO_HZ FULL will not work with unstable sched clock);
return false;
}
#endif
@@ -343,8 +344,6 @@ static int tick_nohz_init_all(void)
void __init tick_nohz_init(void)
{
- int cpu;
-
if (!have_nohz_full_mask) {
if (tick_nohz_init_all() 0)
return;
--
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/
[RFC PATCH] scsi: Add failfast mode to avoid infinite retry loop
Hello,
This patch adds scsi device failfast mode to avoid infinite retry loop.
Currently, scsi error handling in scsi_decide_disposition() and
scsi_io_completion() unconditionally retries on some errors. This is because
retryable errors are thought to be temporary and the scsi device will soon
recover from those errors. Normally, such retry policy is appropriate because
the device will soon recover from temporary error state.
But there is no guarantee that device is able to recover from error state
immediately. Some hardware error may prevent device from recovering.
Therefore hardware error can results in infinite command retry loop. In fact,
CHECK_CONDITION error with the sense-key = UNIT_ATTENTION caused infinite
retry loop in our environment. As the comments in kernel source code says,
UNIT_ATTENTION means the device must have been a power glitch and expected
to immediately recover from the state. But it seems that hardware error
caused permanent UNIT_ATTENTION error.
To solve the above problem, this patch introduces scsi device failfast mode.
If failfast mode is enabled, retry counts of all scsi commands are limited to
scsi-allowed(== SD_MAX_RETRIES == 5). All commands are prohibited to retry
infinitely, and immediately fails when the retry count exceeds upper limit.
Failfast mode is useful on mission critical systems which are required
to keep running flawlessly because they need to failover to the secondary
system once they detect failures.
On default, failfast mode is disabled because failfast policy is not suitable
for most use cases which can accept I/O latency due to device hardware error.
To enable failfast mode(default disabled):
# echo 1 /sys/bus/scsi/devices/X:X:X:X/failfast
To disable:
# echo 0 /sys/bus/scsi/devices/X:X:X:X/failfast
Furthermore, I'm planning to make the upper limit count configurable.
Currently, I have two plans to implement it:
(1) set same upper limit count on all errors.
(2) set upper limit count on each error.
The first implementation is simple and easy to implement but not flexible.
Someone wants to set different upper limit count on each errors depends on the
scsi device they use. The second implementation satisfies such requirement
but can be too fine-grained and annoying to configure because scsi error
codes are so much. The default 5 times retry may too much on some errors but
too few on other errors.
Which would be the appropriate implementation?
Any comments or suggestions are welcome as usual.
Signed-off-by: Eiichi Tsukata eiichi.tsukata...@hitachi.com
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: linux-s...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/scsi/scsi_error.c | 44 +++-
drivers/scsi/scsi_lib.c| 10 ++
drivers/scsi/scsi_sysfs.c |8 +++-
include/scsi/scsi_device.h |1 +
4 files changed, 45 insertions(+), 18 deletions(-)
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index 2150596..1b6a4b6 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -1442,7 +1442,7 @@ int scsi_noretry_cmd(struct scsi_cmnd *scmd)
*/
int scsi_decide_disposition(struct scsi_cmnd *scmd)
{
- int rtn;
+ int rtn, disposition;
/*
* if the device is offline, then we clearly just pass the result back
@@ -1492,12 +1492,14 @@ int scsi_decide_disposition(struct scsi_cmnd *scmd)
* and not get stuck in a loop.
*/
case DID_SOFT_ERROR:
- goto maybe_retry;
+ disposition = NEEDS_RETRY;
+ goto limited_retry;
case DID_IMM_RETRY:
- return NEEDS_RETRY;
-
+ disposition = NEEDS_RETRY;
+ goto retry;
case DID_REQUEUE:
- return ADD_TO_MLQUEUE;
+ disposition = ADD_TO_MLQUEUE;
+ goto retry;
case DID_TRANSPORT_DISRUPTED:
/*
* LLD/transport was disrupted during processing of the IO.
@@ -1506,7 +1508,8 @@ int scsi_decide_disposition(struct scsi_cmnd *scmd)
* based on its timers and recovery capablilities if
* there are enough retries.
*/
- goto maybe_retry;
+ disposition = NEEDS_RETRY;
+ goto limited_retry;
case DID_TRANSPORT_FAILFAST:
/*
* The transport decided to failfast the IO (most likely
@@ -1524,7 +1527,8 @@ int scsi_decide_disposition(struct scsi_cmnd *scmd)
/* fallthrough */
case DID_BUS_BUSY:
case DID_PARITY:
- goto maybe_retry;
+ disposition = NEEDS_RETRY;
+ goto limited_retry;
case DID_TIME_OUT:
/*
* when we scan the bus, we get timeout messages for
@@ -1566,17 +1570,21 @@ int scsi_decide_disposition(struct scsi_cmnd *scmd)
Re: [PATCH 09/15] NTB: Use DMA Engine to Transmit and Receive
On Fri, Aug 2, 2013 at 10:35 AM, Jon Mason jon.ma...@intel.com wrote:
Allocate and use a DMA engine channel to transmit and receive data over
NTB. If none is allocated, fall back to using the CPU to transfer data.
Cc: Dan Williams d...@fb.com
Cc: Vinod Koul vinod.k...@intel.com
Cc: Dave Jiang dave.ji...@intel.com
Signed-off-by: Jon Mason jon.ma...@intel.com
---
drivers/ntb/ntb_hw.c| 17 +++
drivers/ntb/ntb_hw.h|1 +
drivers/ntb/ntb_transport.c | 285
---
3 files changed, 258 insertions(+), 45 deletions(-)
diff --git a/drivers/ntb/ntb_hw.c b/drivers/ntb/ntb_hw.c
index 1d8e551..014222c 100644
--- a/drivers/ntb/ntb_hw.c
+++ b/drivers/ntb/ntb_hw.c
@@ -350,6 +350,23 @@ int ntb_read_remote_spad(struct ntb_device *ndev,
unsigned int idx, u32 *val)
}
/**
+ * ntb_get_mw_base() - get addr for the NTB memory window
+ * @ndev: pointer to ntb_device instance
+ * @mw: memory window number
+ *
+ * This function provides the base address of the memory window specified.
+ *
+ * RETURNS: address, or NULL on error.
+ */
+resource_size_t ntb_get_mw_base(struct ntb_device *ndev, unsigned int mw)
+{
+ if (mw = ntb_max_mw(ndev))
+ return 0;
+
+ return pci_resource_start(ndev-pdev, MW_TO_BAR(mw));
+}
+
+/**
* ntb_get_mw_vbase() - get virtual addr for the NTB memory window
* @ndev: pointer to ntb_device instance
* @mw: memory window number
diff --git a/drivers/ntb/ntb_hw.h b/drivers/ntb/ntb_hw.h
index b03de80..ab5f768 100644
--- a/drivers/ntb/ntb_hw.h
+++ b/drivers/ntb/ntb_hw.h
@@ -240,6 +240,7 @@ int ntb_write_local_spad(struct ntb_device *ndev,
unsigned int idx, u32 val);
int ntb_read_local_spad(struct ntb_device *ndev, unsigned int idx, u32 *val);
int ntb_write_remote_spad(struct ntb_device *ndev, unsigned int idx, u32
val);
int ntb_read_remote_spad(struct ntb_device *ndev, unsigned int idx, u32
*val);
+resource_size_t ntb_get_mw_base(struct ntb_device *ndev, unsigned int mw);
void __iomem *ntb_get_mw_vbase(struct ntb_device *ndev, unsigned int mw);
u64 ntb_get_mw_size(struct ntb_device *ndev, unsigned int mw);
void ntb_ring_sdb(struct ntb_device *ndev, unsigned int idx);
diff --git a/drivers/ntb/ntb_transport.c b/drivers/ntb/ntb_transport.c
index f7380e9..73a35e4 100644
--- a/drivers/ntb/ntb_transport.c
+++ b/drivers/ntb/ntb_transport.c
@@ -47,6 +47,7 @@
*/
#include linux/debugfs.h
#include linux/delay.h
+#include linux/dmaengine.h
#include linux/dma-mapping.h
#include linux/errno.h
#include linux/export.h
@@ -68,6 +69,10 @@ static unsigned char max_num_clients;
module_param(max_num_clients, byte, 0644);
MODULE_PARM_DESC(max_num_clients, Maximum number of NTB transport clients);
+static unsigned int copy_bytes = 1024;
+module_param(copy_bytes, uint, 0644);
+MODULE_PARM_DESC(copy_bytes, Threshold under which NTB will use the CPU to
copy instead of DMA);
+
struct ntb_queue_entry {
/* ntb_queue list reference */
struct list_head entry;
@@ -76,6 +81,13 @@ struct ntb_queue_entry {
void *buf;
unsigned int len;
unsigned int flags;
+
+ struct ntb_transport_qp *qp;
+ union {
+ struct ntb_payload_header __iomem *tx_hdr;
+ struct ntb_payload_header *rx_hdr;
+ };
+ unsigned int index;
};
struct ntb_rx_info {
@@ -86,6 +98,7 @@ struct ntb_transport_qp {
struct ntb_transport *transport;
struct ntb_device *ndev;
void *cb_data;
+ struct dma_chan *dma_chan;
bool client_ready;
bool qp_link;
@@ -99,6 +112,7 @@ struct ntb_transport_qp {
struct list_head tx_free_q;
spinlock_t ntb_tx_free_q_lock;
void __iomem *tx_mw;
+ dma_addr_t tx_mw_raw;
unsigned int tx_index;
unsigned int tx_max_entry;
unsigned int tx_max_frame;
@@ -114,6 +128,7 @@ struct ntb_transport_qp {
unsigned int rx_index;
unsigned int rx_max_entry;
unsigned int rx_max_frame;
+ dma_cookie_t last_cookie;
void (*event_handler) (void *data, int status);
struct delayed_work link_work;
@@ -129,9 +144,14 @@ struct ntb_transport_qp {
u64 rx_err_no_buf;
u64 rx_err_oflow;
u64 rx_err_ver;
+ u64 rx_memcpy;
+ u64 rx_async;
u64 tx_bytes;
u64 tx_pkts;
u64 tx_ring_full;
+ u64 tx_err_no_buf;
+ u64 tx_memcpy;
+ u64 tx_async;
};
struct ntb_transport_mw {
@@ -381,7 +401,7 @@ static ssize_t debugfs_read(struct file *filp, char
__user *ubuf, size_t count,
char *buf;
ssize_t ret, out_offset, out_count;
- out_count = 600;
+ out_count = 1000;
buf = kmalloc(out_count, GFP_KERNEL);
if (!buf)
@@ -396,6 +416,10 @@ static ssize_t debugfs_read(struct file *filp, char
__user *ubuf, size_t count,
Re: dmaengine: make dma_channel_rebalance() NUMA aware
Le 19/08/2013 11:36, Dan Williams a écrit :
+ for_each_online_cpu(cpu)
+ per_cpu_ptr(channel_table[cap], cpu)-chan
+= min_chan(cap, cpu);
...this line-wrap strikes me weird. I think we can afford a few extra
lines and do:
for_each_online_cpu(cpu) {
chan = min_chan(cap, cpu);
per_cpu_ptr(channel_table[cap], cpu)-chan = chan;
}
Right, here's a new one.
Brice
dmaengine: make dma_channel_rebalance() NUMA aware
dma_channel_rebalance() currently distributes channels by processor ID.
These IDs often change with the BIOS, and the order isn't related to
the DMA channel list (related to PCI bus ids).
* On my SuperMicro dual E5 machine, first socket has processor IDs [0-7]
(and [16-23] for hyperthreads), second socket has [8-15]+[24-31]
= channels are properly allocated to local CPUs.
* On Dells R720 with same processors, first socket has even processor IDs,
second socket has odd numbers
= half the processors get channels on the remote socket, causing
cross-NUMA traffic and lower DMA performance.
Change nth_chan() to return the channel with min table_count and in the
NUMA node of the given CPU, if any. If none, the (non-local) channel with
min table_count is returned. nth_chan() is therefore renamed into min_chan()
since we don't iterate until the nth channel anymore. In practice, the
behavior is the same because first channels are taken first and are then
ignored because they got an additional reference.
The new code has a slightly higher complexity since we always scan the
entire list of channels for finding the minimal table_count (instead
of stopping after N chans), and because we check whether the CPU is in the
DMA device locality mask. Overall we still have time complexity =
number of chans x number of processors. This rebalance is rarely used,
so this won't hurt.
On the above SuperMicro machine, channels are still allocated the same.
On the Dells, there are no locality issue anymore (MEMCPY channel X goes
to processor X and to its hyperthread sibling).
Signed-off-by: Brice Goglin brice.gog...@inria.fr
---
drivers/dma/dmaengine.c | 64 +++-
1 file changed, 37 insertions(+), 27 deletions(-)
Index: linux-3.11-rc3/drivers/dma/dmaengine.c
===
--- linux-3.11-rc3.orig/drivers/dma/dmaengine.c 2013-08-19 10:56:27.375013873
+0200
+++ linux-3.11-rc3/drivers/dma/dmaengine.c 2013-08-19 11:41:43.782440861
+0200
@@ -376,20 +376,30 @@ void dma_issue_pending_all(void)
EXPORT_SYMBOL(dma_issue_pending_all);
/**
- * nth_chan - returns the nth channel of the given capability
+ * dma_chan_is_local - returns true if the channel is in the same numa-node as
the cpu
+ */
+static bool dma_chan_is_local(struct dma_chan *chan, int cpu)
+{
+ int node = dev_to_node(chan-device-dev);
+ return node == -1 || cpumask_test_cpu(cpu, cpumask_of_node(node));
+}
+
+/**
+ * min_chan - returns the channel with min count and in the same numa-node as
the cpu
* @cap: capability to match
- * @n: nth channel desired
+ * @cpu: cpu index which the channel should be close to
*
- * Defaults to returning the channel with the desired capability and the
- * lowest reference count when 'n' cannot be satisfied. Must be called
- * under dma_list_mutex.
+ * If some channels are close to the given cpu, the one with the lowest
+ * reference count is returned. Otherwise, cpu is ignored and only the
+ * reference count is taken into account.
+ * Must be called under dma_list_mutex.
*/
-static struct dma_chan *nth_chan(enum dma_transaction_type cap, int n)
+static struct dma_chan *min_chan(enum dma_transaction_type cap, int cpu)
{
struct dma_device *device;
struct dma_chan *chan;
- struct dma_chan *ret = NULL;
struct dma_chan *min = NULL;
+ struct dma_chan *localmin = NULL;
list_for_each_entry(device, dma_device_list, global_node) {
if (!dma_has_cap(cap, device-cap_mask) ||
@@ -398,27 +408,22 @@ static struct dma_chan *nth_chan(enum dm
list_for_each_entry(chan, device-channels, device_node) {
if (!chan-client_count)
continue;
- if (!min)
- min = chan;
- else if (chan-table_count min-table_count)
+ if (!min || chan-table_count min-table_count)
min = chan;
- if (n-- == 0) {
- ret = chan;
- break; /* done */
- }
+ if (dma_chan_is_local(chan, cpu))
+ if (!localmin ||
+ chan-table_count localmin-table_count)
+ localmin = chan;
}
-
[RFC PATCH 04/11] [CLEANUP] trace-cmd: Split out the communication with listener from setup_network()
Split out the communication with listener from the setup_network() for avoiding
duplicate codes between listen mode and virt-server mode.
Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
---
trace-record.c | 119 +---
1 file changed, 62 insertions(+), 57 deletions(-)
diff --git a/trace-record.c b/trace-record.c
index ac9f70a..6a096bd 100644
--- a/trace-record.c
+++ b/trace-record.c
@@ -1607,59 +1607,13 @@ static int create_recorder(struct buffer_instance
*instance, int cpu, int extrac
exit(0);
}
-static void setup_network(void)
+static void communicate_with_listener(int fd)
{
- struct tracecmd_output *handle;
- struct addrinfo hints;
- struct addrinfo *result, *rp;
- int sfd, s;
- ssize_t n;
char buf[BUFSIZ];
- char *server;
- char *port;
- char *p;
- int cpu;
- int i;
-
- if (!strchr(host, ':')) {
- server = strdup(localhost);
- if (!server)
- die(alloctating server);
- port = host;
- host = server;
- } else {
- host = strdup(host);
- if (!host)
- die(alloctating server);
- server = strtok_r(host, :, p);
- port = strtok_r(NULL, :, p);
- }
-
- memset(hints, 0, sizeof(hints));
- hints.ai_family = AF_UNSPEC;
- hints.ai_socktype = SOCK_STREAM;
-
- s = getaddrinfo(server, port, hints, result);
- if (s != 0)
- die(getaddrinfo: %s, gai_strerror(s));
-
- for (rp = result; rp != NULL; rp = rp-ai_next) {
- sfd = socket(rp-ai_family, rp-ai_socktype,
-rp-ai_protocol);
- if (sfd == -1)
- continue;
-
- if (connect(sfd, rp-ai_addr, rp-ai_addrlen) != -1)
- break;
- close(sfd);
- }
-
- if (!rp)
- die(Can not connect to %s:%s, server, port);
-
- freeaddrinfo(result);
+ ssize_t n;
+ int cpu, i;
- n = read(sfd, buf, 8);
+ n = read(fd, buf, 8);
/* Make sure the server is the tracecmd server */
if (memcmp(buf, tracecmd, 8) != 0)
@@ -1670,13 +1624,13 @@ static void setup_network(void)
sprintf(buf, %d, cpu_count);
/* include \0 */
- write(sfd, buf, strlen(buf)+1);
+ write(fd, buf, strlen(buf)+1);
/* write the pagesize (in ASCII) */
sprintf(buf, %d, page_size);
/* include \0 */
- write(sfd, buf, strlen(buf)+1);
+ write(fd, buf, strlen(buf)+1);
/*
* If we are using IPV4 and our page size is greater than
@@ -1691,14 +1645,14 @@ static void setup_network(void)
if (use_tcp) {
/* Send one option */
- write(sfd, 1, 2);
+ write(fd, 1, 2);
/* Size 4 */
- write(sfd, 4, 2);
+ write(fd, 4, 2);
/* use TCP */
- write(sfd, TCP, 4);
+ write(fd, TCP, 4);
} else
/* No options */
- write(sfd, 0, 2);
+ write(fd, 0, 2);
client_ports = malloc_or_die(sizeof(int) * cpu_count);
@@ -1708,7 +1662,7 @@ static void setup_network(void)
*/
for (cpu = 0; cpu cpu_count; cpu++) {
for (i = 0; i BUFSIZ; i++) {
- n = read(sfd, buf+i, 1);
+ n = read(fd, buf+i, 1);
if (n != 1)
die(Error, reading server ports);
if (!buf[i] || buf[i] == ',')
@@ -1719,6 +1673,57 @@ static void setup_network(void)
buf[i] = 0;
client_ports[cpu] = atoi(buf);
}
+}
+
+static void setup_network(void)
+{
+ struct tracecmd_output *handle;
+ struct addrinfo hints;
+ struct addrinfo *result, *rp;
+ int sfd, s;
+ char *server;
+ char *port;
+ char *p;
+
+ if (!strchr(host, ':')) {
+ server = strdup(localhost);
+ if (!server)
+ die(alloctating server);
+ port = host;
+ host = server;
+ } else {
+ host = strdup(host);
+ if (!host)
+ die(alloctating server);
+ server = strtok_r(host, :, p);
+ port = strtok_r(NULL, :, p);
+ }
+
+ memset(hints, 0, sizeof(hints));
+ hints.ai_family = AF_UNSPEC;
+ hints.ai_socktype = SOCK_STREAM;
+
+ s = getaddrinfo(server, port, hints, result);
+ if (s != 0)
+ die(getaddrinfo: %s, gai_strerror(s));
+
+ for (rp = result; rp != NULL; rp = rp-ai_next) {
+ sfd = socket(rp-ai_family, rp-ai_socktype,
+rp-ai_protocol);
[RFC PATCH 10/11] trace-cmd: Add virt-server mode for a virtualization environment
Add the virt-server mode for a virtualization environment based on the listen
mode for networking. This mode works like client/server mode over TCP/UDP,
but it uses virtio-serial channel instead of IP network. Using networking for
collecting trace data of guests is generally high overhead caused by processing
of the network stack.
We use virtio-serial for collecting trace data of guests. virtio-serial is a
simple communication path between the guest and the host. Moreover,
since virtio-serial and ftrace can use splice(2), memory copying is not
occurred on the guests. Therefore, total overhead for collecting trace data
of the guests will be reduced. The implementation of guests will be shown
in another patch.
virt-server uses two kinds of virtio-serial I/Fs:
(1) agent-ctl-path(UNIX domain socket)
= control path of an agent trace-cmd each guest
(2) trace-path-cpuX(named pipe)
= trace data path each vcpu
Those I/Fs must be stored as follows:
(1) /tmp/trace-cmd/virt/agent-ctl-path
(2) /tmp/trace-cmd/virt/guest domain/trace-path-cpuX
If we run virt-server, agent-ctl-path I/F is automatically created because
virt-server operates as a server mode of UNIX domain socket. However,
trace-path-cpuX is not automatically created because we need to separate
trace data for each guests.
How to set up
1. Run virt-server on a host before booting guests
# trace-cmd virt-server
2. Make guest domain directory
# mkdir -p /tmp/trace-cmd/virt/domain
# chmod 710 /tmp/trace-cmd/virt/domain
# chgrp qemu /tmp/trace-cmd/virt/domain
3. Make FIFO on the host
# mkfifo /tmp/trace-cmd/virt/domain/trace-path-cpu{0,1,...,X}.{in,out}
4. Set up of virtio-serial pipe of a guest on the host
Add the following tags to domain XML files.
# virsh edit domain
channel type='unix'
source mode='connect' path='/tmp/trace-cmd/virt/agent-ctl-path'/
target type='virtio' name='agent-ctl-path'/
/channel
channel type='pipe'
source path='/tmp/trace-cmd/virt/domain/trace-path-cpu0'/
target type='virtio' name='trace-path-cpu0'/
/channel
... (cpu1, cpu2, ...)
5. Boot the guest
# virsh start domain
6. Check I/F of virtio-serial on the guest
# ls /dev/virtio-ports
...
agent-ctl-path
...
trace-path-cpu0
...
Next, the user will run trace-cmd with record --virt options or other options
for virtualization on the guest.
This patch adds only minimum features of virt-server as follows:
Features
- Add virt-server subcommand
- Create I/F directory(/tmp/trace-cmd/virt/)
- Use named pipe I/Fs of virtio-serial for trace data paths
- Use UNIX domain socket for connecting agents on guests
- Use splice(2) for collecting trace data of guests
Restrictions
- Use libvirt when we boot guests
Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
---
Documentation/trace-cmd-virt-server.1.txt | 89 ++
trace-cmd.c |3
trace-cmd.h |4
trace-listen.c| 439 -
trace-msg.c | 51 ++-
trace-recorder.c | 54 +++-
trace-usage.c | 10 +
7 files changed, 540 insertions(+), 110 deletions(-)
create mode 100644 Documentation/trace-cmd-virt-server.1.txt
diff --git a/Documentation/trace-cmd-virt-server.1.txt
b/Documentation/trace-cmd-virt-server.1.txt
new file mode 100644
index 000..4168a04
--- /dev/null
+++ b/Documentation/trace-cmd-virt-server.1.txt
@@ -0,0 +1,89 @@
+TRACE-CMD-VIRT-SERVER(1)
+
+
+NAME
+
+trace-cmd-virt-server - listen for incoming connection to record tracing of
+guests' clients
+
+SYNOPSIS
+
+*trace-cmd virt-server ['OPTIONS']
+
+DESCRIPTION
+---
+The trace-cmd(1) virt-server sets up UNIX domain socket I/F for communicating
+with guests' clients that run 'trace-cmd-record(1)' with the *--virt* option.
+When a connection is made, and the guest's client sends data, it will create a
+file called 'trace.DOMAIN.dat'. Where DOMAIN is the name of the guest named
+by libvirt.
+
+OPTIONS
+---
+*-D*::
+This options causes trace-cmd listen to go into a daemon mode and run in
+the background.
+
+*-d* 'dir'::
+This option specifies a directory to write the data files into.
+
+*-o* 'filename'::
+This option overrides the default 'trace' in the 'trace.DOMAIN.dat' that
+is created when guest's client connects.
+
+*-l* 'filename'::
+This option writes the output messages to a log file instead of standard
output.
+
+SET UP
+--
+Here, an example is written as follows:
+
+1. Run virt-server on a host
+ # trace-cmd virt-server
+
+2. Make guest domain directory
+ # mkdir -p /tmp/trace-cmd/virt/DOMAIN
+ # chmod 710 /tmp/trace-cmd/virt/DOMAIN
+ # chgrp qemu /tmp/trace-cmd/virt/DOMAIN
+
+3. Make FIFO on the host
+ # mkfifo
[RFC PATCH 08/11] trace-cmd: Apply the trace-msg protocol for communication between a server and clients
Apply trace-msg protocol for communication between a server and clients. Currently, trace-listen(server) and trace-record -N(client) operate as follows: server client listen to socket fd connect to socket fd accept the client send tracecmd + receive tracecmd check tracecmd send cpus receive cpus + print cpus=XXX + send pagesize | receive pagesize + print pagesize=XXX + send option | receive option --+ understand option send port_array + receive port_array understand port_array send meta data receive meta data ---+ record meta data (snip) read block --- start sending trace data on child processes --- --- When client finishes sending trace data --- close(socket fd) read size = 0 close(socket fd) Currently, all messages are unstructured character strings, so server(client) using the protocol must parse the unstructured messages. Since it is hard to add complex contents in the protocol, structured binary message trace-msg is introduced as the communication protocol. By applying this patch, server and client operate as follows: server client listen to socket fd connect to socket fd accept the client send a connection message(MSG_TCONNECT) receive MSG_TCONNECT + send tracecmd +-MSG_RCONNECT- receive MSG_RCONNECT check tracecmd send cpus,pagesize,option(MSG_TINIT) receive MSG_TINIT ---+ print cpus=XXX print pagesize=XXX understand option send port_array +--MSG_RINIT- receive MSG_RINIT understand port_array send meta data(MSG_SENDMETA) receive MSG_SENDMETA + record meta data (snip) send a message to finish sending meta data | (MSG_FINMETA) receive MSG_FINMETA -+ read block --- start sending trace data on child processes --- --- When client finishes sending trace data --- send MSG_CLOSE receive MSG_CLOSE ---+ close(socket fd)close(socket fd) By introducing trace-msg protocol, when a client tries to connect to the server, the client sends a message(MSG_TCONNECT) first. When client finishes sending trace data, the client sends a message(MSG_CLOSE). This message protocol is incompatible with the previous unstructured message protocol. So, if an old(new)-version client tries to connect to an new(old)-version server, the operation should be stopped. Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com --- Makefile |2 trace-cmd.h| 12 + trace-listen.c | 144 +- trace-msg.c| 782 trace-msg.h| 21 ++ trace-output.c |4 trace-record.c | 77 -- 7 files changed, 836 insertions(+), 206 deletions(-) create mode 100644 trace-msg.c create mode 100644 trace-msg.h diff --git a/Makefile b/Makefile index 51c6f39..cebe553 100644 --- a/Makefile +++ b/Makefile @@ -314,7 +314,7 @@ KERNEL_SHARK_OBJS = $(TRACE_VIEW_OBJS) $(TRACE_GRAPH_OBJS) $(TRACE_GUI_OBJS) \ PEVENT_LIB_OBJS = event-parse.o trace-seq.o parse-filter.o parse-utils.o TCMD_LIB_OBJS = $(PEVENT_LIB_OBJS) trace-util.o trace-input.o trace-ftrace.o \ trace-output.o trace-recorder.o trace-restore.o trace-usage.o \ - trace-blk-hack.o kbuffer-parse.o + trace-blk-hack.o kbuffer-parse.o trace-msg.o PLUGIN_OBJS = plugin_hrtimer.o plugin_kmem.o plugin_sched_switch.o \ plugin_mac80211.o plugin_jbd2.o plugin_function.o plugin_kvm.o \ diff --git a/trace-cmd.h b/trace-cmd.h index cbbc6ed..5ae5313 100644 --- a/trace-cmd.h +++ b/trace-cmd.h @@ -248,6 +248,18 @@ void tracecmd_stop_recording(struct tracecmd_recorder *recorder); void tracecmd_stat_cpu(struct trace_seq *s, int cpu); long tracecmd_flush_recording(struct tracecmd_recorder *recorder); +/* for clients */ +int tracecmd_msg_connect_to_server(int fd); +int tracecmd_msg_metadata_send(int fd, char *buf, int size); +int tracecmd_msg_finish_sending_metadata(int fd); +void tracecmd_msg_send_close_msg(); + +/* for server */ +int tracecmd_msg_set_connection(int fd); +int tracecmd_msg_initial_setting(int fd, int *cpus,
[RFC PATCH 05/11] [CLEANUP] trace-cmd: Split out the connect waiting loop from do_listen()
Split out the connect waiting loop from do_listen() for avoiding duplicate codes
between listen mode and virt-server mode.
Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
---
trace-listen.c | 45 ++---
1 file changed, 26 insertions(+), 19 deletions(-)
diff --git a/trace-listen.c b/trace-listen.c
index 6c1bcac..c741fa4 100644
--- a/trace-listen.c
+++ b/trace-listen.c
@@ -580,14 +580,35 @@ static void clean_up(int sig)
} while (ret 0);
}
+static void do_accept_loop(int sfd)
+{
+ struct sockaddr_storage peer_addr;
+ socklen_t peer_addr_len;
+ int cfd, pid;
+
+ peer_addr_len = sizeof(peer_addr);
+
+ do {
+ cfd = accept(sfd, (struct sockaddr *)peer_addr,
+peer_addr_len);
+ printf(connected!\n);
+ if (cfd 0 errno == EINTR)
+ continue;
+ if (cfd 0)
+ pdie(connecting);
+
+ pid = do_connection(cfd, peer_addr, peer_addr_len);
+ if (pid 0)
+ add_process(pid);
+
+ } while (!done);
+}
+
static void do_listen(char *port)
{
struct addrinfo hints;
struct addrinfo *result, *rp;
- int sfd, s, cfd;
- struct sockaddr_storage peer_addr;
- socklen_t peer_addr_len;
- int pid;
+ int sfd, s;
if (!debug)
signal_setup(SIGCHLD, clean_up);
@@ -621,21 +642,7 @@ static void do_listen(char *port)
if (listen(sfd, backlog) 0)
pdie(listen);
- peer_addr_len = sizeof(peer_addr);
-
- do {
- cfd = accept(sfd, (struct sockaddr *)peer_addr,
peer_addr_len);
- printf(connected!\n);
- if (cfd 0 errno == EINTR)
- continue;
- if (cfd 0)
- pdie(connecting);
-
- pid = do_connection(cfd, peer_addr, peer_addr_len);
- if (pid 0)
- add_process(pid);
-
- } while (!done);
+ do_accept_loop(sfd);
kill_clients();
}
--
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/
[RFC PATCH 11/11] trace-cmd: Add --virt option for record mode
Add --virt option for record mode for a virtualization environment.
If we use this option on a guest, we can send trace data in low overhead.
This is because guests can send trace data to a host without copying the data
by using splice(2).
The format is:
trace-cmd record --virt -e sched*
Restriction
This feature can use from kernel-3.6 which supports splice_read for ftrace
and splice_write for virtio-serial.
Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
---
Documentation/trace-cmd-record.1.txt | 11 +-
trace-cmd.h |3 +-
trace-msg.c | 35 --
trace-msg.h |4 ++
trace-record.c | 66 --
5 files changed, 110 insertions(+), 9 deletions(-)
diff --git a/Documentation/trace-cmd-record.1.txt
b/Documentation/trace-cmd-record.1.txt
index 832a257..7eb8ac9 100644
--- a/Documentation/trace-cmd-record.1.txt
+++ b/Documentation/trace-cmd-record.1.txt
@@ -240,6 +240,15 @@ OPTIONS
timestamp to gettimeofday which will allow wall time output from the
timestamps reading the created 'trace.dat' file.
+*--virt*::
+This option is usded on a guest in a virtualization environment. If a host
+is running trace-cmd virt-server, this option is used to have the data
+sent to the host with virtio-serial like *-N* option. (see also
+trace-cmd-virt-server(1))
+
+Note: This option is not supported with latency tracer plugins:
+ wakeup, wakeup_rt, irqsoff, preemptoff and preemptirqsoff
+
EXAMPLES
@@ -302,7 +311,7 @@ SEE ALSO
trace-cmd(1), trace-cmd-report(1), trace-cmd-start(1), trace-cmd-stop(1),
trace-cmd-extract(1), trace-cmd-reset(1), trace-cmd-split(1),
-trace-cmd-list(1), trace-cmd-listen(1)
+trace-cmd-list(1), trace-cmd-listen(1), trace-cmd-virt-server(1)
AUTHOR
--
diff --git a/trace-cmd.h b/trace-cmd.h
index b4c2267..5d895ff 100644
--- a/trace-cmd.h
+++ b/trace-cmd.h
@@ -251,7 +251,8 @@ void tracecmd_stat_cpu(struct trace_seq *s, int cpu);
long tracecmd_flush_recording(struct tracecmd_recorder *recorder);
/* for clients */
-int tracecmd_msg_connect_to_server(int fd);
+int tracecmd_msg_connect_to_server_nw(int fd);
+int tracecmd_msg_connect_to_server_virt(int fd);
int tracecmd_msg_metadata_send(int fd, char *buf, int size);
int tracecmd_msg_finish_sending_metadata(int fd);
void tracecmd_msg_send_close_msg();
diff --git a/trace-msg.c b/trace-msg.c
index 251e99c..cdeeed3 100644
--- a/trace-msg.c
+++ b/trace-msg.c
@@ -30,6 +30,7 @@
#include stdio.h
#include unistd.h
#include arpa/inet.h
+#include sys/stat.h
#include sys/types.h
#include linux/types.h
@@ -503,11 +504,12 @@ static int tracecmd_msg_wait_for_msg(int fd, struct
tracecmd_msg **msg)
return 0;
}
-int tracecmd_msg_connect_to_server(int fd)
+static int tracecmd_msg_connect_to_server(int fd, bool nw)
{
struct tracecmd_msg *msg;
u32 reply_cmd, cmd;
int i, ret, cpus;
+ char buf[PATH_MAX];
/* connect to a server */
cmd = MSG_TCONNECT;
@@ -529,9 +531,24 @@ int tracecmd_msg_connect_to_server(int fd)
} while (reply_cmd != MSG_RINIT);
cpus = ntohl(msg-data.rinit.cpus);
- client_ports = malloc_or_die(sizeof(int) * cpus);
- for (i = 0; i cpus; i++)
- client_ports[i] = ntohl(msg-data.rinit.port_array[i]);
+ if (nw) {
+ client_ports = malloc_or_die(sizeof(int) * cpus);
+ for (i = 0; i cpus; i++)
+ client_ports[i] =
+ ntohl(msg-data.rinit.port_array[i]);
+ } else {
+ virt_sfds = malloc_or_die(sizeof(int) * cpus);
+
+ /* Open data paths of virtio-serial */
+ for (i = 0; i cpus; i++) {
+ snprintf(buf, PATH_MAX, TRACE_PATH_CPU, i);
+ virt_sfds[i] = open(buf, O_WRONLY);
+ if (virt_sfds[i] 0) {
+ warning(Cannot open %s, TRACE_PATH_CPU, i);
+ return -errno;
+ }
+ }
+ }
/* Next, send meta data */
send_metadata = true;
@@ -543,6 +560,16 @@ error:
return ret;
}
+int tracecmd_msg_connect_to_server_nw(int fd)
+{
+ return tracecmd_msg_connect_to_server(fd, true);
+}
+
+int tracecmd_msg_connect_to_server_virt(int fd)
+{
+ return tracecmd_msg_connect_to_server(fd, false);
+}
+
static bool process_option(struct tracecmd_msg_opt *opt)
{
/* currently the only option we have is to us TCP */
diff --git a/trace-msg.h b/trace-msg.h
index 9ec95e5..d1f7321 100644
--- a/trace-msg.h
+++ b/trace-msg.h
@@ -2,6 +2,9 @@
#define _TRACE_MSG_H_
#include stdbool.h
+#define VIRTIO_PORTS /dev/virtio-ports/
+#define AGENT_CTL_PATH VIRTIO_PORTS agent-ctl-path
+#define TRACE_PATH_CPU
[RFC PATCH 01/11] [TRIVIAL] trace-cmd: Delete the variable iface in trace-listen
iface in trace-listen is not used any more, so it is deleted.
Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
---
trace-listen.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/trace-listen.c b/trace-listen.c
index 8503b50..dec1c00 100644
--- a/trace-listen.c
+++ b/trace-listen.c
@@ -653,7 +653,6 @@ void trace_listen(int argc, char **argv)
{
char *logfile = NULL;
char *port = NULL;
- char *iface;
int daemon = 0;
int c;
@@ -672,7 +671,7 @@ void trace_listen(int argc, char **argv)
{NULL, 0, NULL, 0}
};
- c = getopt_long (argc-1, argv+1, +hp:o:d:i:l:D,
+ c = getopt_long (argc-1, argv+1, +hp:o:d:l:D,
long_options, option_index);
if (c == -1)
break;
@@ -683,9 +682,6 @@ void trace_listen(int argc, char **argv)
case 'p':
port = optarg;
break;
- case 'i':
- iface = optarg;
- break;
case 'd':
output_dir = optarg;
break;
--
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/27] drivers/dma: don't check resource with devm_ioremap_resource
On Tue, Jul 23, 2013 at 08:01:37PM +0200, Wolfram Sang wrote: devm_ioremap_resource does sanity checks on the given resource. No need to duplicate this in the driver. Signed-off-by: Wolfram Sang w...@the-dreams.de Sorry looks like I missed this and instead applied a similar patch from Julia last week. I should have taken this instead. My bad... ~Vinod --- Please apply via the subsystem-tree. drivers/dma/mmp_pdma.c |3 --- drivers/dma/mmp_tdma.c |3 --- 2 files changed, 6 deletions(-) diff --git a/drivers/dma/mmp_pdma.c b/drivers/dma/mmp_pdma.c index c26699f..7eba967 100644 --- a/drivers/dma/mmp_pdma.c +++ b/drivers/dma/mmp_pdma.c @@ -778,9 +778,6 @@ static int mmp_pdma_probe(struct platform_device *op) pdev-dev = op-dev; iores = platform_get_resource(op, IORESOURCE_MEM, 0); - if (!iores) - return -EINVAL; - pdev-base = devm_ioremap_resource(pdev-dev, iores); if (IS_ERR(pdev-base)) return PTR_ERR(pdev-base); diff --git a/drivers/dma/mmp_tdma.c b/drivers/dma/mmp_tdma.c index 9b93665..1f1885a 100644 --- a/drivers/dma/mmp_tdma.c +++ b/drivers/dma/mmp_tdma.c @@ -549,9 +549,6 @@ static int mmp_tdma_probe(struct platform_device *pdev) } iores = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!iores) - return -EINVAL; - tdev-base = devm_ioremap_resource(pdev-dev, iores); if (IS_ERR(tdev-base)) return PTR_ERR(tdev-base); -- 1.7.10.4 -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 06/11] [CLEANUP] trace-cmd: Split out the communication with client from process_client()
Split out the communication with client from process_client() for avoiding
duplicate codes between listen mode and virt-server mode.
Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
---
trace-listen.c | 163
1 file changed, 116 insertions(+), 47 deletions(-)
diff --git a/trace-listen.c b/trace-listen.c
index c741fa4..f29dd35 100644
--- a/trace-listen.c
+++ b/trace-listen.c
@@ -283,22 +283,12 @@ static int open_udp(const char *node, const char *port,
int *pid,
return num_port;
}
-static void process_client(const char *node, const char *port, int fd)
+static int communicate_with_client(int fd, int *cpus, int *pagesize)
{
- char **temp_files;
char buf[BUFSIZ];
char *option;
- int *port_array;
- int *pid_array;
- int pagesize;
- int start_port;
- int udp_port;
int options;
int size;
- int cpus;
- int cpu;
- int pid;
- int ofd;
int n, s, t, i;
/* Let the client know what we are */
@@ -308,31 +298,31 @@ static void process_client(const char *node, const char
*port, int fd)
n = read_string(fd, buf, BUFSIZ);
if (n == BUFSIZ)
/** ERROR **/
- return;
+ return -1;
- cpus = atoi(buf);
+ *cpus = atoi(buf);
- plog(cpus=%d\n, cpus);
- if (cpus 0)
- return;
+ plog(cpus=%d\n, *cpus);
+ if (*cpus 0)
+ return -1;
/* next read the page size */
n = read_string(fd, buf, BUFSIZ);
if (n == BUFSIZ)
/** ERROR **/
- return;
+ return -1;
- pagesize = atoi(buf);
+ *pagesize = atoi(buf);
- plog(pagesize=%d\n, pagesize);
- if (pagesize = 0)
- return;
+ plog(pagesize=%d\n, *pagesize);
+ if (*pagesize = 0)
+ return -1;
/* Now the number of options */
n = read_string(fd, buf, BUFSIZ);
if (n == BUFSIZ)
/** ERROR **/
- return;
+ return -1;
options = atoi(buf);
@@ -341,18 +331,18 @@ static void process_client(const char *node, const char
*port, int fd)
n = read_string(fd, buf, BUFSIZ);
if (n == BUFSIZ)
/** ERROR **/
- return;
+ return -1;
size = atoi(buf);
/* prevent a client from killing us */
if (size MAX_OPTION_SIZE)
- return;
+ return -1;
option = malloc_or_die(size);
do {
t = size;
s = 0;
s = read(fd, option+s, t);
if (s = 0)
- return;
+ return -1;
t -= s;
s = size - t;
} while (t);
@@ -361,18 +351,53 @@ static void process_client(const char *node, const char
*port, int fd)
free(option);
/* do we understand this option? */
if (!s)
- return;
+ return -1;
}
if (use_tcp)
plog(Using TCP for live connection\n);
- /* Create the client file */
+ return 0;
+}
+
+static int create_client_file(const char *node, const char *port)
+{
+ char buf[BUFSIZ];
+ int ofd;
+
snprintf(buf, BUFSIZ, %s.%s:%s.dat, output_file, node, port);
ofd = open(buf, O_RDWR | O_CREAT | O_TRUNC, 0644);
if (ofd 0)
pdie(Can not create file %s, buf);
+ return ofd;
+}
+
+static void destroy_all_readers(int cpus, int *pid_array, const char *node,
+ const char *port)
+{
+ int cpu;
+
+ for (cpu = 0; cpu cpus; cpu++) {
+ if (pid_array[cpu] 0) {
+ kill(pid_array[cpu], SIGKILL);
+ waitpid(pid_array[cpu], NULL, 0);
+ delete_temp_file(node, port, cpu);
+ pid_array[cpu] = 0;
+ }
+ }
+}
+
+static int *create_all_readers(int cpus, const char *node, const char *port,
+ int pagesize, int fd)
+{
+ char buf[BUFSIZ];
+ int *port_array;
+ int *pid_array;
+ int start_port;
+ int udp_port;
+ int cpu;
+ int pid;
port_array = malloc_or_die(sizeof(int) * cpus);
pid_array = malloc_or_die(sizeof(int) * cpus);
@@ -382,13 +407,17 @@ static void process_client(const char *node, const char
*port, int fd)
/* Now create a UDP port for each CPU */
for (cpu = 0; cpu cpus; cpu++) {
- udp_port = open_udp(node, port, pid, cpu, pagesize,
start_port);
+
[RFC PATCH 07/11] [CLEANUP] trace-cmd: Split out binding a port and fork reader from open_udp()
Split out binding a port and fork reader from open_udp() for avoiding duplicate
codes between listen mode and virt-server mode.
Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
---
trace-listen.c | 34 ++
1 file changed, 26 insertions(+), 8 deletions(-)
diff --git a/trace-listen.c b/trace-listen.c
index f29dd35..bf9ef9d 100644
--- a/trace-listen.c
+++ b/trace-listen.c
@@ -228,13 +228,12 @@ static void process_udp_child(int sfd, const char *host,
const char *port,
#define START_PORT_SEARCH 1500
#define MAX_PORT_SEARCH 6000
-static int open_udp(const char *node, const char *port, int *pid,
- int cpu, int pagesize, int start_port)
+static int udp_bind_a_port(int start_port, int *sfd)
{
struct addrinfo hints;
struct addrinfo *result, *rp;
- int sfd, s;
char buf[BUFSIZ];
+ int s;
int num_port = start_port;
again:
@@ -250,15 +249,15 @@ static int open_udp(const char *node, const char *port,
int *pid,
pdie(getaddrinfo: error opening udp socket);
for (rp = result; rp != NULL; rp = rp-ai_next) {
- sfd = socket(rp-ai_family, rp-ai_socktype,
-rp-ai_protocol);
- if (sfd 0)
+ *sfd = socket(rp-ai_family, rp-ai_socktype,
+ rp-ai_protocol);
+ if (*sfd 0)
continue;
- if (bind(sfd, rp-ai_addr, rp-ai_addrlen) == 0)
+ if (bind(*sfd, rp-ai_addr, rp-ai_addrlen) == 0)
break;
- close(sfd);
+ close(*sfd);
}
if (rp == NULL) {
@@ -270,6 +269,12 @@ static int open_udp(const char *node, const char *port,
int *pid,
freeaddrinfo(result);
+ return num_port;
+}
+
+static void fork_udp_reader(int sfd, const char *node, const char *port,
+ int *pid, int cpu, int pagesize)
+{
*pid = fork();
if (*pid 0)
@@ -279,6 +284,19 @@ static int open_udp(const char *node, const char *port,
int *pid,
process_udp_child(sfd, node, port, cpu, pagesize);
close(sfd);
+}
+
+static int open_udp(const char *node, const char *port, int *pid,
+ int cpu, int pagesize, int start_port)
+{
+ int sfd;
+ int num_port;
+
+ num_port = udp_bind_a_port(start_port, sfd);
+ if (num_port 0)
+ return num_port;
+
+ fork_udp_reader(sfd, node, port, pid, cpu, pagesize);
return num_port;
}
--
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/
[RFC PATCH 09/11] trace-cmd: Use poll(2) to wait for a message
Use poll(2) to wait for a message. If a client/server cannot send a message for
any reasons, the current server/client will wait in a blocking read operation.
So, we use poll(2) for avoiding remaining in a blocking state.
This modification avoids to try to connect to an old-version client. An
old-version network server will send a message tracecmd first, and an
old-version client will start to send cpu number, pagesize, and option.
By introducing trace-msg, the new client sends a message MSG_TCONNECT first,
so the start point of the connection is different. If the old client tries
to connect to the new network server, the server should make the connection
close. A server applied this patch will die when the predetermined time will
have elapsed.
Note that if a new client tries to connect to an old server, the new client
will automatically die. This is because the new client which received the
inappropriate message tracecmd will die.
Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
---
trace-msg.c | 50 ++
1 file changed, 42 insertions(+), 8 deletions(-)
diff --git a/trace-msg.c b/trace-msg.c
index 777ea1f..36117cd 100644
--- a/trace-msg.c
+++ b/trace-msg.c
@@ -435,6 +435,27 @@ error:
return -ENOMSG;
}
+#define MSG_WAIT_MSEC 5000
+
+/*
+ * A return value of 0 indicates time-out
+ */
+static int tracecmd_msg_recv_wait(int fd, char *buf, struct tracecmd_msg **msg)
+{
+ struct pollfd pfd;
+ int ret;
+
+ pfd.fd = fd;
+ pfd.events = POLLIN;
+ ret = poll(pfd, 1, MSG_WAIT_MSEC);
+ if (ret 0) {
+ return -errno;
+ } else if (ret == 0)
+ return -ETIMEDOUT;
+
+ return tracecmd_msg_recv(fd, buf);
+}
+
static void *tracecmd_msg_buf_access(struct tracecmd_msg *msg, int offset)
{
return (void *)msg + offset;
@@ -448,9 +469,12 @@ static int tracecmd_msg_wait_for_msg(int fd, struct
tracecmd_msg **msg)
u32 cmd;
int ret;
- ret = tracecmd_msg_recv(fd, msg_tmp);
- if (ret 0)
+ ret = tracecmd_msg_recv_wait(fd, msg_tmp, msg);
+ if (ret 0) {
+ if (ret == -ETIMEDOUT)
+ warning(Connection timed out\n);
return ret;
+ }
*msg = (struct tracecmd_msg *)msg_tmp;
cmd = ntohl((*msg)-cmd);
@@ -549,9 +573,13 @@ int tracecmd_msg_set_connection(int fd)
int ret;
/* wait for connection msg by a client first */
- ret = tracecmd_msg_recv(fd, buf);
+ ret = tracecmd_msg_recv_wait(fd, buf, msg);
if (ret 0) {
- warning(Disconnect);
+ if (ret == -ETIMEDOUT)
+ /* network connection will be started soon */
+ warning(No connection message);
+ else
+ warning(Disconnect);
return ret;
}
@@ -586,9 +614,12 @@ int tracecmd_msg_initial_setting(int fd, int *cpus, int
*pagesize)
u32 size = 0;
u32 cmd;
- ret = tracecmd_msg_recv(fd, buf);
- if (ret 0)
+ ret = tracecmd_msg_recv_wait(fd, buf, msg);
+ if (ret 0) {
+ if (ret == -ETIMEDOUT)
+ warning(Connection timed out\n);
return ret;
+ }
msg = (struct tracecmd_msg *)buf;
cmd = ntohl(msg-cmd);
@@ -724,9 +755,12 @@ int tracecmd_msg_collect_metadata(int ifd, int ofd)
int ret;
do {
- ret = tracecmd_msg_recv(ifd, buf);
+ ret = tracecmd_msg_recv_wait(ifd, buf, msg);
if (ret 0) {
- warning(reading client);
+ if (ret == -ETIMEDOUT)
+ warning(Connection timed out\n);
+ else
+ warning(reading client);
return ret;
}
--
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/
[RFC PATCH 03/11] [BUGFIX]trace-cmd: Quit from splice(read) if there are no data
Quit from splice(read) for avoiding to do splice(write) if there are no data. When splice(read) returns negative or 0, that means no data. So, the recorder does not need to do splice(write). Note: This patch is related to https://lkml.org/lkml/2013/7/21/200. If the patch of the link is not applied, splice(write) for virtio-serial induces kernel oops when there are no data. This patch always avoids to do splice(write) in the case, so this patch is needed. Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com --- trace-recorder.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/trace-recorder.c b/trace-recorder.c index 7db5f3e..520d486 100644 --- a/trace-recorder.c +++ b/trace-recorder.c @@ -337,7 +337,10 @@ static long splice_data(struct tracecmd_recorder *recorder) warning(recorder error in splice input); return -1; } - } + if (errno == EINTR) + return 0; + } else if (ret == 0) + return 0; ret = splice(recorder-brass[0], NULL, recorder-fd, NULL, recorder-page_size, 3 /* and NON_BLOCK */); -- 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/
[RFC PATCH 00/11] trace-cmd: Support the feature recording trace data of guests on the host
Hi Steven,
I'm considering Integrated trace which is a trace merging system for a
virtualization environment. Why do we need this system? Because we want to
analyze latency problems for a virtualization environment. For example, a host
OS runs two guest OSs and those OSs are sharing HW devices like CPUs, NIC, disk,
etc. In the situation, it will be difficult to directly tackle I/O delay
problems. This is because we don't have any methods which all trace data are
shown. The integrated trace will solve this problem by merging trace data in
chronological order. Moreover, the integrated trace will support the feature
collecting trace data of guests and a host on the host.
I want to support above two big features in trace-cmd. However, trace-cmd does
not have following features yet:
a) server and client for a virtualization environment
b) structured message platform between guests and a host
c) agent feature of a client
d) merge feature of trace data of multiple guests and a host in chronological
order
This patch set supports above a) and b) features.
overall view
++++
Guest | a), c) || a), c) | client/agent
^ ++++
| ^ ^ ^ ^
|===|=|===|===
| v b)v v b)v
v +--+
Host| a) | server
+--+
||output|| ||
\/ \/ \/
/+ /+ /+
| 010101 | | 101010 | | 100101 | binary data
| 010100 | | 010100 | | 110011 |
++ ++ ++
\ /
\---/
|| d)
\/
/---+
| (guest1) 123456: sched_switch... | text data
| (guest2) 123458: kmem_free... |
| (host) 123500: kvm_exit (guest1)|
| (host) 123510: kvm_entry(guest1)|
| (guest1) 123550: sched_switch... |
+---+
a) server and client for a virtualization environment
trace-cmd has listen mode for network, but using network will be a high cost
operation for inducing a lot of memory copying. From kernel-3.6, the
virtio-console driver supports splice_write and ftrace supports steal for
fops. So, guest clients of trace-cmd can send trace data without copying memory
by using splice(2). If guest clients use virtio-serial, the server also needs to
support virtio-serial I/F.
b) structured message platform between guests and a host
Currently, a server(clients) sends unstructured character string to
clients(server), so clients(server) must parse the unstructured messages.
Since it is hard to add complex contents in the protocol, structured binary
message trace-msg is introduced as the communication protocol.
c) agent feature of a client
Current trace-cmd client can operate only as record mode, so the client
will send trace data to the server immediately. However, when an user tries to
collect trace data of multiple guests on a host, the user must log in to
each guest. This is hard to use, I think. So, trace-cmd client had better
support agent mode which receives a message from the server.
d) merge feature of trace data of multiple guests and a host in chronological
order
Current trace-cmd cannot merge trace data of multiple guests and a host in
chronological order. If an user wants to analyze an I/O delay problem of a
guest, the user will want to check trace data of all guests and the host in a
file. However, trace-cmd does not support a merge feature yet, the user must
make a merging script. So, trace-cmd had better support a merge feature for
multiple files for virtualization.
For a), this patch introduces virt-server and record --virt modes for
achieving low-overhead communication of trace data of guests. virt-server is a
server mode for collecting trace data of guests. On the other hand,
record --virt mode is a guest client for sending trace data of the guest.
Although these functions are similar to listen and record -N modes each,
these do not use network but use virtio-serial for low-overhead communication.
For b), this patch series introduce specific message protocol in order to handle
communication messages with 8 commands. When we extend any messages, using
structured message will be easier than using unstructured message.
How to use
1. Run virt-server on a host
# trace-cmd virt-server
2. Make guest domain directory
# mkdir -p /tmp/trace-cmd/virt/domain
# chmod 710 /tmp/trace-cmd/virt/domain
# chgrp qemu /tmp/trace-cmd/virt/domain
3. Make FIFO on the host
# mkfifo /tmp/trace-cmd/virt/domain/trace-path-cpu{0,1,...,X}.{in,out}
4. Set up of virtio-serial pipe of a guest on the host
Add the
[RFC PATCH 02/11] [BUGFIX] trace-cmd: Add waitpid() when recorders are destoried
Add waitpid() when recorders are destroyed for avoiding zombie processes.
When udp_port is inappropriate, a parent process will destroy all child recorder
processes. Currently, the process does not wait for the termination of the
children, so those recorders can become zombie processes if the parent process
cannot die at once due to any reasons.
Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
---
trace-listen.c |1 +
1 file changed, 1 insertion(+)
diff --git a/trace-listen.c b/trace-listen.c
index dec1c00..6c1bcac 100644
--- a/trace-listen.c
+++ b/trace-listen.c
@@ -446,6 +446,7 @@ static void process_client(const char *node, const char
*port, int fd)
for (cpu = 0; cpu cpus; cpu++) {
if (pid_array[cpu] 0) {
kill(pid_array[cpu], SIGKILL);
+ waitpid(pid_array[cpu], NULL, 0);
delete_temp_file(node, port, cpu);
pid_array[cpu] = 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] [BUGFIX] crash/ioapic: Prevent crash_kexec() from deadlocking of ioapic_lock
* Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com wrote:
Prevent crash_kexec() from deadlocking of ioapic_lock.
s/of/on
When crash_kexec() is executed on a cpu, the cpu will get
ioapic_lock in disable_IO_APIC(). So if the cpu gets NMI
while locking ioapic_lock, a deadlock wiil happen. In
s/will
this patch, ioapic_lock is initialized before
disable_IO_APIC().
To confirm this deadlocking, you'll set up as follows:
s/deadlocking/deadlock
1. Add mdelay(1000) after raw_spin_lock_irqsave() in
native_ioapic_set_affinity()@arch/x86/kernel/apic/io_apic.c
Although the deadlocking can occur without this modification, it will
increase the potential of the deadlocking problem.
s/deadlocking/deadlock
2. Build and install the kernel
3. Set up the OS which will run panic() and kexec when NMI is injected
# echo kernel.unknown_nmi_panic=1 /etc/sysctl.conf
# vim /etc/default/grub
add nmi_watchdog=0 crashkernel=256M in GRUB_CMDLINE_LINUX line
# grub2-mkconfig
4. Reboot the OS
5. Run following command for each vcpu on the guest
# while true; do echo CPU num /proc/irq/IO-APIC-edge or
IO-APIC-fasteoi/smp_affinitity; done;
By running this command, cpus will get ioapic_lock for setting affinity.
6. Inject NMI (push a dump button or execute 'virsh inject-nmi domain' if
you
use VM)
After injecting NMI, panic() is called in an nmi-handler context.
Then, kexec will normally run in panic(), but the operation will be stopped
by deadlock of ioapic_lock in crash_kexec()-machine_crash_shutdown()-
s/of/on
native_machine_crash_shutdown()-disable_IO_APIC()-clear_IO_APIC()-
clear_IO_APIC_pin()-ioapic_read_entry().
I suppose we could do this patch if it's a common
occurance.
A few minor details need fixing:
Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: x...@kernel.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: Andi Kleen a...@linux.intel.com
Cc: Seiji Aguchi seiji.agu...@hds.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Sebastian Andrzej Siewior sebast...@breakpoint.cc
Cc: Joerg Roedel j...@8bytes.org
Cc: Zhang Yanfei zhangyan...@cn.fujitsu.com
Cc: Eric W. Biederman ebied...@xmission.com
Cc: Gleb Natapov g...@redhat.com
Cc: Marcelo Tosatti mtosa...@redhat.com
Cc: linux-kernel@vger.kernel.org
Cc: sta...@vger.kernel.org
---
arch/x86/include/asm/apic.h|2 ++
arch/x86/kernel/apic/io_apic.c |5 +
arch/x86/kernel/crash.c|4
3 files changed, 11 insertions(+)
diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index f8119b5..ddb06af 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -715,4 +715,6 @@ static inline void exiting_ack_irq(void)
ack_APIC_irq();
}
+extern void ioapic_lock_init(void);
+
#endif /* _ASM_X86_APIC_H */
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 9ed796c..2816c07 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1534,6 +1534,11 @@ void intel_ir_io_apic_print_entries(unsigned int apic,
}
}
+void ioapic_lock_init(void)
+{
+ raw_spin_lock_init(ioapic_lock);
+}
Please name this ioapic_zap_locks() to make clear that this
is crash handling related.
+
__apicdebuginit(void) print_IO_APIC(int ioapic_idx)
{
union IO_APIC_reg_00 reg_00;
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 74467fe..ea039d5 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -129,6 +129,10 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
lapic_shutdown();
#if defined(CONFIG_X86_IO_APIC)
Please enhance this #ifdef while at it.
+ /*
+ * Prevent crash_kexec() from deadlocking of ioapic_lock.
+ */
s/of/on.
Also, single-line comment can go /* here */.
+ ioapic_lock_init();
disable_IO_APIC();
#endif
#ifdef CONFIG_HPET_TIMER
Thanks,
Ingo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] dmaengine: make dmatest less noisy
On Mon, Aug 19, 2013 at 10:31 AM, Joe Perches j...@perches.com wrote: -static unsigned int threads_per_chan = 1; +static unsigned int threads_per_chan = 8; module_param(threads_per_chan, uint, S_IRUGO); MODULE_PARM_DESC(threads_per_chan, Number of threads to start per channel (default: 1)); This is unrelated and makes the MODULE_PARAM_DESC below it have the incorrect default. Argh sorry, unrelated patches in the tree. As I don't have loadable modules enabled in this system I have to alter the compile defaults and compile the module into the kernel :-/ Thanks for fixing the real issue the right way! Yours, Linus Walleij -- 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/
[tip:core/locking] generic-ipi/locking: Fix misleading smp_call_function_any() description
Commit-ID: 15e71911fcc655508e02f767a3d9b8b138051d2b Gitweb: http://git.kernel.org/tip/15e71911fcc655508e02f767a3d9b8b138051d2b Author: Xie XiuQi xiexi...@huawei.com AuthorDate: Mon, 29 Jul 2013 11:52:24 +0800 Committer: Ingo Molnar mi...@kernel.org CommitDate: Mon, 19 Aug 2013 09:03:50 +0200 generic-ipi/locking: Fix misleading smp_call_function_any() description Fix locking description: after commit 8969a5ede0f9e17da4b9437 (generic-ipi: remove kmalloc()), wait = 0 can be guaranteed because we don't kmalloc() anymore. Signed-off-by: Xie XiuQi xiexi...@huawei.com Cc: Sheng Yang sh...@linux.intel.com Cc: Peter Zijlstra a.p.zijls...@chello.nl Cc: Jens Axboe jens.ax...@oracle.com Cc: Rusty Russell ru...@rustcorp.com.au Link: http://lkml.kernel.org/r/51f5e6f8.1000...@huawei.com Signed-off-by: Ingo Molnar mi...@kernel.org --- kernel/smp.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/kernel/smp.c b/kernel/smp.c index fe9f773..b1c9034 100644 --- a/kernel/smp.c +++ b/kernel/smp.c @@ -278,8 +278,6 @@ EXPORT_SYMBOL(smp_call_function_single); * @wait: If true, wait until function has completed. * * Returns 0 on success, else a negative status code (if no cpus were online). - * Note that @wait will be implicitly turned on in case of allocation failures, - * since we fall back to on-stack allocation. * * Selection preference: * 1) current cpu if in @mask -- 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/
[tip:x86/spinlocks] x86/kvm/guest: Fix sparse warning: symbol ' klock_waiting' was not declared as static
Commit-ID: 36bd621337c91a1ecda588e5bbbae8dd9698bae7
Gitweb: http://git.kernel.org/tip/36bd621337c91a1ecda588e5bbbae8dd9698bae7
Author: Raghavendra K T raghavendra...@linux.vnet.ibm.com
AuthorDate: Fri, 16 Aug 2013 15:08:41 +0530
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Mon, 19 Aug 2013 11:49:50 +0200
x86/kvm/guest: Fix sparse warning: symbol 'klock_waiting' was not declared as
static
It was not declared as static since it was thought to be used by
pv-flushtlb earlier.
Signed-off-by: Raghavendra K T raghavendra...@linux.vnet.ibm.com
Cc: g...@redhat.com
Cc: pbonz...@redhat.com
Cc: Jiri Kosina triv...@kernel.org
Link:
http://lkml.kernel.org/r/1376645921-8056-1-git-send-email-raghavendra...@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar mi...@kernel.org
---
arch/x86/kernel/kvm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index b8ef630..56e2fa4 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -529,7 +529,7 @@ arch_initcall(activate_jump_labels);
#ifdef CONFIG_PARAVIRT_SPINLOCKS
/* Kick a cpu by its apicid. Used to wake up a halted vcpu */
-void kvm_kick_cpu(int cpu)
+static void kvm_kick_cpu(int cpu)
{
int apicid;
unsigned long flags = 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 07/25] dma: of: make error message more meaningful by adding the node name
On Wed, Jul 31, 2013 at 04:14:35PM +0200, Lothar Waßmann wrote:
Signed-off-by: Lothar Waßmann l...@karo-electronics.de
Applied, thanks
~Vinod
---
drivers/dma/of-dma.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c
index 75334bd..0b88dd3 100644
--- a/drivers/dma/of-dma.c
+++ b/drivers/dma/of-dma.c
@@ -160,7 +160,8 @@ struct dma_chan *of_dma_request_slave_channel(struct
device_node *np,
count = of_property_count_strings(np, dma-names);
if (count 0) {
- pr_err(%s: dma-names property missing or empty\n, __func__);
+ pr_err(%s: dma-names property of node '%s' missing or empty\n,
+ __func__, np-full_name);
return NULL;
}
--
1.7.2.5
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] dma: mmp_pdma: fix a memory alloc error
On Thu, Aug 01, 2013 at 10:27:47AM +0800, Xiang Wang wrote: 2013/7/29 Vinod Koul vinod.k...@intel.com: On Thu, Jul 25, 2013 at 10:22:50AM +0800, Xiang Wang wrote: Btw its generally a good idea to remove the parts not required for further discussion Would you please explain a little more about why we should use GFP_NOWAIT here? This memory is not dedicated for DMA controller. Do we have special reasons to use GFP_NOWAIT? Thanks! There are few reasons - the dma requests can be triggered from atomic context - so for above you can argue to use the GFP_ATOMIC and the guideline for dma drivers [1] was discussed briefly ~Vinod [1]: http://lkml.indiana.edu/hypermail/linux/kernel/0911.1/02316.html -- Hi, Vinod Thanks for your explanation. But want to double confirm with you that the memory alloc in my patch is in probe function, still need to use GFP_NOWAIT? Thanks! Yes I would recommend it ~Vinod -- 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/
