Re: [PATCH] blkdev: Fix blkdev_open to release the bdev on error
On Mon, Dec 07, 2015 at 10:49:05AM -0800, Linus Torvalds wrote:
> On Mon, Dec 7, 2015 at 10:05 AM, Suzuki K. Poulose
> wrote:
> > blkdev_open() doesn't release the bdev, it attached to a given
> > inode, if blkdev_get() fails (e.g, due to absence of a device).
> > This can cause kernel crashes when the original filesystem
> > tries to flush the data during evict_inode.
>
> Ugh. This code is a mess. Al, can you please comment?
>
> So what happens is that when "blkdev_get()" fails, it will do a
> bdput() on the bdev.
Yes.
> But blkdev_open() hasn't done a bdget(). It's done a bd_acquire().
> Which will do the whole "add inodes to bd_inodes".
Yes.
> And yes,
> bd_forget() will undo that.
It would, but there's no reason to drop the cached pointer to bdev.
> IOW, the path looks simple and apparently fixes an oops, but I'd like
> much more of an explanation for what happens, because it all feels
> wrong to me. Why doesn't the bdput() end up undoing the bd_acquire()
> properly?
Because it doesn't work that way. ->i_bdev is just a cached result of
lookup by device number. Once found, it stays there for as long as
neither the struct inode nor struct block_device are freed.
It does *NOT* pin struct block_device. Note that we have two kinds of block
device inodes - ones coallocated with struct block_device (those are unique
per major/minor, live on bdevfs and can't be seen directly) and ones aliasing
the first kind. Those live on normal filesystems.
Pagecache lives in ->i_data of the bdevfs inode; aliasing ones have their
->i_data empty and ->i_mapping pointing to ->i_data of the bdevfs inode.
That guarantees the cache coherency between those guys.
Now, simply having ->i_bdev point to struct block_device does not affect
the lifetime of the latter in any way. All aliases are dissociated from
block_device when bdevfs inode is evicted; block_device is dissociated
from aliasing inode when that aliasing inode is evicted. bdev_lock
provides the atomicity there.
_Opening_ an alias (any of them) does pin block_device down. So when an
aliasing inode is open, we can safely use its ->i_mapping in normal
pagecache-related code and have everything work correctly. Accessing
->i_mapping when inode isn't open is valid only if filesystem code is
sure it's pointing to its own ->i_data (and pointless in any case).
And that's what 9p ->evict_inode() is doing - it's trying to evict not
the pages in its ->i_data (which would be empty for block device), but
the pages in its ->i_mapping. IOW, the pagecache shared by all aliasing
inodes. Which is obviously bogus, regardless of lifetime rules violation -
mknod /tmp/foo b 8 1 && dd count=1 /dev/null && rm /tmp/foo
should not blow the cache of /dev/sda1, no matter which fs type we happen to
use for /tmp. And 9p will try to do just that.
Fortunately, no other ->evict_inode() instance is doing anything of that sort,
so we just need to fix that bogosity in 9p one.
As for the bdev eviction, bdput() acts exactly like iput(). In fact, it is
iput() of the coallocated bdevfs inode. It can stay around with zero
refcount; same as any other inode, memory pressure would eventually push
them out. It does *NOT* pin the driver when not opened, BTW.
Anyway, the fix for 9p bogosity follows; it definitely fixes a bug there,
and I'm fairly sure that it fixes the bug that had been reported.
A confirmation would be nice, of course...
Signed-off-by: Al Viro
---
diff --git a/fs/9p/vfs_inode.c b/fs/9p/vfs_inode.c
index 699941e..5110785 100644
--- a/fs/9p/vfs_inode.c
+++ b/fs/9p/vfs_inode.c
@@ -451,9 +451,9 @@ void v9fs_evict_inode(struct inode *inode)
{
struct v9fs_inode *v9inode = V9FS_I(inode);
- truncate_inode_pages_final(inode->i_mapping);
+ truncate_inode_pages_final(>i_data);
clear_inode(inode);
- filemap_fdatawrite(inode->i_mapping);
+ filemap_fdatawrite(>i_data);
v9fs_cache_inode_put_cookie(inode);
/* clunk the fid stashed in writeback_fid */
--
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: Fixing full name in patchwork
Sudip Mukherjee writes: > On Mon, Dec 07, 2015 at 08:03:54PM +0200, Kalle Valo wrote: >> Hi Sudip, >> >> Sudip Mukherjee writes: >> >> > We were dereferencing cmd first and checking for NULL later. Lets first >> > check for NULL. >> > >> > Signed-off-by: Sudip Mukherjee >> >> I noticed that your name in git log is not your full name: >> >> commit 0a38c8e1b592c16d959da456f425053e323a5153 >> Author: sudip >> Date: Tue Nov 24 13:51:38 2015 +0530 >> >> This is because for some reason in patchwork your fullname is just >> "sudip": >> >> https://patchwork.kernel.org/patch/7688171/ >> >> Could you please fix your name in patchwork so that in the future we can >> use your correct full name? The problem is that I don't know exactly how >> to do this but it should be possible because I remember someone else >> having a similar problem and he was able to fix it. > > I have also noticed the patch. Anyway, I have created a profile in > patchwork and given full name. Hopefully that should solve the problem. At least now your name in the patchwork link above looks correct: Sudip Mukherjee - Nov. 24, 2015, 8:21 a.m. Thanks for fixing this. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: sunxi: Extend the simple gates and handle the Allwinner H3
Hi Jean-Francois, On Tue, Dec 08, 2015 at 07:42:26AM +0100, Jean-Francois Moine wrote: > On Mon, 7 Dec 2015 08:31:02 -0600 > Rob Herring wrote: > > > On Sun, Dec 06, 2015 at 10:04:12AM +0100, Jean-Francois Moine wrote: > > > The H3 has a clock gate definition similar to the other Allwinner SoCs, > > > but with a different parent clock for each single gate. > > > > > > Adding the names of the parent clocks in both the source and output clocks > > > permits the use of the simple-gates driver to define the bus gates > > > of all known Allwinner SoCs. > > > > > > Signed-off-by: Jean-Francois Moine > > > --- > > > This patch replaces a part of Jens Kuske's patch > > > [PATCH v5 1/4] clk: sunxi: Add H3 clocks support > > > --- > > > Documentation/devicetree/bindings/clock/sunxi.txt | 25 > > > +++ > > > drivers/clk/sunxi/clk-simple-gates.c | 14 - > > > 2 files changed, 38 insertions(+), 1 deletion(-) > > > > > > diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt > > > b/Documentation/devicetree/bindings/clock/sunxi.txt > > > index 8a47b77..5736e6d 100644 > > > --- a/Documentation/devicetree/bindings/clock/sunxi.txt > > > +++ b/Documentation/devicetree/bindings/clock/sunxi.txt > > > @@ -70,6 +70,7 @@ Required properties: > > > "allwinner,sun8i-a23-usb-clk" - for usb gates + resets on A23 > > > "allwinner,sun9i-a80-usb-mod-clk" - for usb gates + resets on A80 > > > "allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80 > > > + "allwinner,sunxi-gates-clk" - simple gates > > > > > > Required properties for all clocks: > > > - reg : shall be the control register address for the clock. > > > @@ -93,6 +94,12 @@ The "allwinner,sun9i-a80-mmc-config-clk" clock also > > > requires: > > > - #reset-cells : shall be set to 1 > > > - resets : shall be the reset control phandle for the mmc block. > > > > > > +The "allwinner,sunxi-gates-clk" clock also requires: > > > +- clock-names : corresponding names of the parent clocks > > > +when the output clocks have different parents. > > > +These names must be 4 characters long and must appear as a prefix in > > > +the names of the output clocks. See example. > > > + > > > > I don't think you should be encoding relationships of clocks using the > > name strings. We describe relationships in DT via parent/child or > > phandles. > > As you know, in the H3, each of the 49 output clock has one of the 4 > main clocks as its source. > There are 3 options for defining the source of each clock: > 1- all definitions are in the DT, > 2- some definitions are in the DT, some other ones are hard-coded, > 3- all definitions are hard-coded. Look, we all agreed on a solution that raised all objections, but yours. I'm going to take Jens patch. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[PATCH v2 78/71] ncr5380: Add support for HP 53C400A-based cards (C2502)
HP C2502 cards (based on 53C400A chips) use different magic numbers for
software-based I/O address configuration than other cards.
The configuration is also extended to allow setting the IRQ.
Move the configuration to a new function magic_configure() and move
magic the magic numbers into an array. Add new magic numbers for these
HP cards and hp_53c400a module parameter to use them.
Tested with HP C2502 and DTCT-436P.
Signed-off-by: Ondrej Zary
---
drivers/scsi/g_NCR5380.c | 76 --
drivers/scsi/g_NCR5380.h |1 +
2 files changed, 61 insertions(+), 16 deletions(-)
diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
index 42fdeaf..121d143 100644
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -80,6 +80,7 @@ static int ncr_5380;
static int ncr_53c400;
static int ncr_53c400a;
static int dtc_3181e;
+static int hp_53c400a;
static struct override {
NCR5380_map_type NCR5380_map_name;
@@ -225,6 +226,32 @@ static int __init do_DTC3181E_setup(char *str)
#endif
+#ifndef SCSI_G_NCR5380_MEM
+/*
+ * Configure I/O address of 53C400A or DTC 3181 by writing magic numbers
+ * to ports 0x779 and 0x379. Two magic number sequences are known:
+ * 1. for generic NCR 53C400A-based cards and DTC436 chips
+ * 2. for HP C2502 card (also based on 53C400A but different decode logic)
+ */
+static void magic_configure(int idx, u8 irq, u8 magic[])
+{
+ u8 cfg = 0;
+
+ outb(magic[0], 0x779);
+ outb(magic[1], 0x379);
+ outb(magic[2], 0x379);
+ outb(magic[3], 0x379);
+ outb(magic[4], 0x379);
+
+ /* allowed IRQs for HP 53C400A */
+ if (irq != 2 && irq != 3 && irq != 4 && irq != 5 && irq != 7)
+ irq = 0;
+ if (idx >= 0 && idx <= 7)
+ cfg = 0x80 | idx | (irq << 4);
+ outb(cfg, 0x379);
+}
+#endif
+
/**
* generic_NCR5380_detect - look for NCR5380 controllers
* @tpnt: the scsi template
@@ -241,8 +268,9 @@ static int __init generic_NCR5380_detect(struct
scsi_host_template *tpnt)
static int current_override;
int count;
unsigned int *ports;
+ u8 *magic;
#ifndef SCSI_G_NCR5380_MEM
- int i;
+ int i, port_idx;
unsigned long region_size = 16;
#endif
static unsigned int __initdata ncr_53c400a_ports[] = {
@@ -251,6 +279,12 @@ static int __init generic_NCR5380_detect(struct
scsi_host_template *tpnt)
static unsigned int __initdata dtc_3181e_ports[] = {
0x220, 0x240, 0x280, 0x2a0, 0x2c0, 0x300, 0x320, 0x340, 0
};
+ static u8 ncr_53c400a_magic[] __initdata = {/* 53C400A & DTC 3181 */
+ 0x59, 0xb9, 0xc5, 0xae, 0xa6
+ };
+ static u8 hp_53c400a_magic[] __initdata = { /* HP C2502 */
+ 0x0f, 0x22, 0xf0, 0x20, 0x80
+ };
int flags;
struct Scsi_Host *instance;
struct NCR5380_hostdata *hostdata;
@@ -273,6 +307,8 @@ static int __init generic_NCR5380_detect(struct
scsi_host_template *tpnt)
overrides[0].board = BOARD_NCR53C400A;
else if (dtc_3181e)
overrides[0].board = BOARD_DTC3181E;
+ else if (hp_53c400a)
+ overrides[0].board = BOARD_HP53C400A;
#ifndef SCSI_G_NCR5380_MEM
if (!current_override && isapnp_present()) {
struct pnp_dev *dev = NULL;
@@ -326,10 +362,17 @@ static int __init generic_NCR5380_detect(struct
scsi_host_template *tpnt)
case BOARD_NCR53C400A:
flags = FLAG_NO_DMA_FIXUP;
ports = ncr_53c400a_ports;
+ magic = ncr_53c400a_magic;
+ break;
+ case BOARD_HP53C400A:
+ flags = FLAG_NO_DMA_FIXUP;
+ ports = ncr_53c400a_ports;
+ magic = hp_53c400a_magic;
break;
case BOARD_DTC3181E:
flags = FLAG_NO_DMA_FIXUP;
ports = dtc_3181e_ports;
+ magic = ncr_53c400a_magic;
break;
}
@@ -338,12 +381,7 @@ static int __init generic_NCR5380_detect(struct
scsi_host_template *tpnt)
/* wakeup sequence for the NCR53C400A and DTC3181E */
/* Disable the adapter and look for a free io port */
- outb(0x59, 0x779);
- outb(0xb9, 0x379);
- outb(0xc5, 0x379);
- outb(0xae, 0x379);
- outb(0xa6, 0x379);
- outb(0x00, 0x379);
+ magic_configure(-1, 0, magic);
if (overrides[current_override].NCR5380_map_name !=
PORT_AUTO)
for (i = 0; ports[i]; i++) {
@@ -362,17 +400,14 @@ static int __init generic_NCR5380_detect(struct
scsi_host_template
Re: [PATCH v2] ARM: mm: mark section-aligned portion of rodata NX
On 7 December 2015 at 23:35, Kees Cook wrote:
> When rodata is large enough that it crosses a section boundary after the
> kernel text, mark the rest NX. This is as close to full NX of rodata as
> we can get without splitting page tables or doing section alignment via
> CONFIG_DEBUG_ALIGN_RODATA.
>
> When the config is:
>
> CONFIG_DEBUG_RODATA=y
> # CONFIG_DEBUG_ALIGN_RODATA is not set
>
> Before:
>
> ---[ Kernel Mapping ]---
> 0x8000-0x8010 1M RW NX SHD
> 0x8010-0x80a0 9M ro x SHD
> 0x80a0-0xa000 502M RW NX SHD
>
> After:
>
> ---[ Kernel Mapping ]---
> 0x8000-0x8010 1M RW NX SHD
> 0x8010-0x8070 6M ro x SHD
> 0x8070-0x80a0 3M ro NX SHD
> 0x80a0-0xa000 502M RW NX SHD
>
> Signed-off-by: Kees Cook
> ---
> v2:
> - static declaration, ard
> ---
> arch/arm/kernel/vmlinux.lds.S | 9 +++--
> arch/arm/mm/init.c| 7 ---
> 2 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
> index a6e395c53a48..9c249c71fda1 100644
> --- a/arch/arm/kernel/vmlinux.lds.S
> +++ b/arch/arm/kernel/vmlinux.lds.S
> @@ -8,9 +8,7 @@
> #include
> #include
> #include
> -#ifdef CONFIG_DEBUG_RODATA
> #include
> -#endif
>
> #define PROC_INFO \
> . = ALIGN(4); \
> @@ -337,6 +335,13 @@ SECTIONS
> }
>
> /*
> + * Without CONFIG_DEBUG_ALIGN_RODATA, __start_rodata_section_aligned will
> + * be the first section-aligned location after __start_rodata. Otherwise,
> + * it will be equal to __start_rodata.
> + */
> +__start_rodata_section_aligned = ALIGN(__start_rodata, 1 << SECTION_SHIFT);
> +
> +/*
> * These must never be empty
> * If you have to comment these two assert statements out, your
> * binutils is too old (for other reasons as well)
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index 321d3683dc7c..6b16f6cf4843 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -579,6 +579,9 @@ struct section_perm {
> pmdval_t clear;
> };
>
> +/* First section-aligned location at or after __start_rodata. */
> +extern char __start_rodata_section_aligned[];
> +
> static struct section_perm nx_perms[] = {
> /* Make pages tables, etc before _stext RW (set NX). */
> {
> @@ -596,16 +599,14 @@ static struct section_perm nx_perms[] = {
> .mask = ~PMD_SECT_XN,
> .prot = PMD_SECT_XN,
> },
> -#ifdef CONFIG_DEBUG_ALIGN_RODATA
> /* Make rodata NX (set RO in ro_perms below). */
> {
> .name = "rodata NX",
> - .start = (unsigned long)__start_rodata,
> + .start = (unsigned long)__start_rodata_section_aligned,
> .end= (unsigned long)__init_begin,
What happens if start > end ?
> .mask = ~PMD_SECT_XN,
> .prot = PMD_SECT_XN,
> },
> -#endif
> };
>
> static struct section_perm ro_perms[] = {
> --
> 1.9.1
>
>
> --
> Kees Cook
> Chrome OS & Brillo Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 4/8] ARM: Exynos: use generic cpufreq driver for Exynos5420
On 08.12.2015 03:18, Bartlomiej Zolnierkiewicz wrote:
> From: Thomas Abraham
>
> The new CPU clock type allows the use of cpufreq-dt driver
> for Exynos5420.
>
> Changes by Bartlomiej:
> - split Exynos5420 support from the original patch
> - disable cpufreq if big.LITTLE switcher support is enabled
> - switch to using cpufreq-dt driver
>
> Cc: Tomasz Figa
> Cc: Kukjin Kim
> Cc: Javier Martinez Canillas
> Signed-off-by: Thomas Abraham
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> arch/arm/mach-exynos/exynos.c | 3 +++
> 1 file changed, 3 insertions(+)
I think this is actually now your patch, not Thomas any more. :)
>
> diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
> index 1c47aee..7a89c9d 100644
> --- a/arch/arm/mach-exynos/exynos.c
> +++ b/arch/arm/mach-exynos/exynos.c
> @@ -230,6 +230,9 @@ static const struct of_device_id exynos_cpufreq_matches[]
> = {
> { .compatible = "samsung,exynos4212", .data = "cpufreq-dt" },
> { .compatible = "samsung,exynos4412", .data = "cpufreq-dt" },
> { .compatible = "samsung,exynos5250", .data = "cpufreq-dt" },
> +#ifndef CONFIG_BL_SWITCHER
> + { .compatible = "samsung,exynos5420", .data = "cpufreq-dt" },
> +#endif
Why not on BL_SWITCHER? Shouldn't be enough to disable ARM_DT_BL_CPUFREQ?
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] perf stat: Change event enable code
On 07/12/15 23:09, Arnaldo Carvalho de Melo wrote: > Em Thu, Dec 03, 2015 at 10:06:39AM +0100, Jiri Olsa escreveu: >> hi, >> while testing ftrace:function event I noticed we create >> stat counters as enabled (except for enable_on_exec couters). >> >> This way we count also filter setup and other config code >> which might be crucial for some events. >> >> Posponing the events enable once everything is ready. >> >> The last patch is RFC as I wasn't sure there's some hidden >> catch about perf_evlist__(enable|disable)_event functions >> I missed.. Adrian? > > They look the same, Adrian? > > Applied the first 6, will give some more time to Adrian to chime in. Looks like there might already be a problem using evsel->threads instead of evlist->threads with the logic relating to evsel->system_wide getting lost - but that happened already in "perf evlist: Factor perf_evlist__(enable|disable) functions". Probably the threads should not be propagated in that case, but it needs more investigation. I will try to look at it today. -- 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/
[PATH TRIVIAL] Documentation: cpu-hotplug: Fix sysfs mount instructions
The instructions for mounting sysfs are inconsistent in instructing to create the directory '/sysfs' but then mounting sysfs to /sys. Also, indentation is slightly off. Signed-off-by: Soren Brinkmann --- Documentation/cpu-hotplug.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt index f9ad5e048b11..dd68821c22d4 100644 --- a/Documentation/cpu-hotplug.txt +++ b/Documentation/cpu-hotplug.txt @@ -150,7 +150,7 @@ an entry as shown below in the output. If this is not mounted, do the following. -#mkdir /sysfs + #mkdir /sys #mount -t sysfs sys /sys Now you should see entries for all present cpu, the following is an example -- 2.6.3.3.g9bb996a -- 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] blkdev: Fix blkdev_open to release the bdev on error
On Mon, Dec 07, 2015 at 06:05:03PM +, Suzuki K. Poulose wrote:
> blkdev_open() doesn't release the bdev, it attached to a given
> inode, if blkdev_get() fails (e.g, due to absence of a device).
> This can cause kernel crashes when the original filesystem
> tries to flush the data during evict_inode.
>
> This can be triggered easily with virtio-9p fs using the following
> simple steps.
???
How can filesystem type affect the behaviour of block devices?
Having mknod /tmp/splat b 8 1; rm /tmp/splat try to evict the pagecache
of /dev/sda1 is simply wrong, no matter what type /tmp happens to have.
And they must share pagecache, or you'll get one hell of cache coherency
problems. As it is, that pagecache belongs to inode on bdevfs (see
fs/block_dev.c; not mountable anywhere visible, the one and only mount is
internal). That inode is tied to struct bdev, ditto for its lifetime.
Block device inodes on anything else have their ->i_mapping pointing to
the corresponding (unique for given major/minor) inode on bdevfs; that
gives us the coherency, but that also means that their *own* pagecache
(->i_data) is empty. Which is just fine, since inode eviction should
get rid of everything in its embedded struct address_space. In case of
block device inodes on ext2, 9p, etc. that amounts to no pages at all.
In case of bdevfs, it contains the page cache of block device.
Aha...
truncate_inode_pages_final(inode->i_mapping);
clear_inode(inode);
filemap_fdatawrite(inode->i_mapping);
in there is obviously wrong - it should be
truncate_inode_pages_final(>i_data);
clear_inode(inode);
filemap_fdatawrite(>i_data);
and if you check other filesystems' ->evict_inode() you'll see the same thing
there.
We should not do bd_forget() upon failing open() - what for? As long as
->i_rdev remains the same, the pointer to struct bdev is valid. It
doesn't pin bdev down; having it (or any other alias) opened does. When
we decide to evict bdev, *all* aliasing inodes are dissociated from it;
none of them is open at that point, so we are OK. When an aliasing inode
gets evicted, we have it dissociated from its ->i_bdev (if any). Since we
only access the ->i_mapping of aliasing inode while its open, those places
are fine and anything that wants ->i_data of alias will simply find it empty.
AFAICS, the cause of your oopsen is that 9p evict_inode is accessing the
object it has no business to touch.
Could you confirm that the patch below fixes your problem?
diff --git a/fs/9p/vfs_inode.c b/fs/9p/vfs_inode.c
index 699941e..5110785 100644
--- a/fs/9p/vfs_inode.c
+++ b/fs/9p/vfs_inode.c
@@ -451,9 +451,9 @@ void v9fs_evict_inode(struct inode *inode)
{
struct v9fs_inode *v9inode = V9FS_I(inode);
- truncate_inode_pages_final(inode->i_mapping);
+ truncate_inode_pages_final(>i_data);
clear_inode(inode);
- filemap_fdatawrite(inode->i_mapping);
+ filemap_fdatawrite(>i_data);
v9fs_cache_inode_put_cookie(inode);
/* clunk the fid stashed in writeback_fid */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/8] ARM: dts: Exynos5420: add CPU OPP properties
On 08.12.2015 03:18, Bartlomiej Zolnierkiewicz wrote:
> From: Thomas Abraham
>
> For Exynos5420 platforms, add CPU operating points for
> migrating from Exynos specific cpufreq driver to using
> generic cpufreq driver.
>
> Changes by Bartlomiej:
> - split Exynos5420 support from the original patch
>
> Changes by Ben Gamari:
> - Port to operating-points-v2
>
> Cc: Kukjin Kim
> Cc: Doug Anderson
> Cc: Javier Martinez Canillas
> Cc: Andreas Faerber
> Cc: Sachin Kamat
Sachin's address does not work neither.
> Cc: Thomas Abraham
Thomas' SoB disappeared.
I see that you directly re-used Thomas' values for voltages and
frequencies. For Exynos5420 we could go down to 200 MHz (for both cores)
but this can be fine-tuned per-board later.
Best regards,
Krzysztof
> Signed-off-by: Ben Gamari
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> arch/arm/boot/dts/exynos5420.dtsi | 122
> ++
> 1 file changed, 122 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi
> b/arch/arm/boot/dts/exynos5420.dtsi
> index 48a0a55..f8f70a5 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -50,6 +50,116 @@
> usbdrdphy1 = _phy1;
> };
>
> + cpu0_opp_table: opp_table0 {
> + compatible = "operating-points-v2";
> + opp-shared;
> + opp00@18 {
> + opp-hz = /bits/ 64 <18>;
> + opp-microvolt = <125>;
> + clock-latency-ns = <14>;
> + };
> + opp01@17 {
> + opp-hz = /bits/ 64 <17>;
> + opp-microvolt = <1212500>;
> + clock-latency-ns = <14>;
> + };
> + opp02@16 {
> + opp-hz = /bits/ 64 <16>;
> + opp-microvolt = <1175000>;
> + clock-latency-ns = <14>;
> + };
> + opp03@15 {
> + opp-hz = /bits/ 64 <15>;
> + opp-microvolt = <1137500>;
> + clock-latency-ns = <14>;
> + };
> + opp04@14 {
> + opp-hz = /bits/ 64 <14>;
> + opp-microvolt = <1112500>;
> + clock-latency-ns = <14>;
> + };
> + opp05@13 {
> + opp-hz = /bits/ 64 <13>;
> + opp-microvolt = <1062500>;
> + clock-latency-ns = <14>;
> + };
> + opp06@12 {
> + opp-hz = /bits/ 64 <12>;
> + opp-microvolt = <1037500>;
> + clock-latency-ns = <14>;
> + };
> + opp07@11 {
> + opp-hz = /bits/ 64 <11>;
> + opp-microvolt = <1012500>;
> + clock-latency-ns = <14>;
> + };
> + opp08@10 {
> + opp-hz = /bits/ 64 <10>;
> + opp-microvolt = < 987500>;
> + clock-latency-ns = <14>;
> + };
> + opp09@9 {
> + opp-hz = /bits/ 64 <9>;
> + opp-microvolt = < 962500>;
> + clock-latency-ns = <14>;
> + };
> + opp10@8 {
> + opp-hz = /bits/ 64 <8>;
> + opp-microvolt = < 937500>;
> + clock-latency-ns = <14>;
> + };
> + opp11@7 {
> + opp-hz = /bits/ 64 <7>;
> + opp-microvolt = < 912500>;
> + clock-latency-ns = <14>;
> + };
> + };
> +
> + cpu1_opp_table: opp_table1 {
> + compatible = "operating-points-v2";
> + opp-shared;
> + opp00@13 {
> + opp-hz = /bits/ 64 <13>;
> + opp-microvolt = <1275000>;
> + clock-latency-ns = <14>;
> + };
> + opp01@12 {
> + opp-hz = /bits/ 64 <12>;
> + opp-microvolt = <1212500>;
> + clock-latency-ns = <14>;
> + };
> + opp02@11 {
> + opp-hz = /bits/ 64 <11>;
> + opp-microvolt = <1162500>;
> + clock-latency-ns = <14>;
> + };
> + opp03@10 {
> + opp-hz = /bits/ 64 <10>;
> + opp-microvolt = <1112500>;
> + clock-latency-ns = <14>;
> + };
> + opp04@9 {
> +
[PATCH v4] acpi, apei, arm64: APEI initial support for aarch64.
From: Tomasz Nowicki
This commit provides APEI arch-specific bits for aarch64
Meanwhile, add a new subfunction "hest_ia_init" for
"acpi_disable_cmcff" which is used by IA-32 Architecture
Corrected Machine Check (CMC).
Signed-off-by: Tomasz Nowicki
Tested-by: Jonathan (Zhixiong) Zhang
Signed-off-by: Fu Wei
---
Changelog:
v4: Rebase to latest kernel version(4.4-rc4).
Move arch_apei_flush_tlb_one into header file as a inline function
Add a new subfunction "hest_ia_init" for "acpi_disable_cmcff".
v3: https://lkml.org/lkml/2015/12/3/521
Remove "acpi_disable_cmcff" from arm64 code,
and wrap it in hest.c by "#if defined(__i386__) || defined(__x86_64__)"
v2: https://lkml.org/lkml/2015/12/2/432
Rebase to latest kernel version(4.4-rc3).
Move arch_apei_flush_tlb_one() to arch/arm64/kernel/acpi.c
v1: https://lkml.org/lkml/2015/8/14/199
Move arch_apei_flush_tlb_one() to arch/arm64/include/asm/apci.h.
Delete arch/arm64/kernel/apei.c.
Add "#ifdef CONFIG_ACPI_APEI" for "acpi_disable_cmcff".
arch/arm64/Kconfig| 1 +
arch/arm64/include/asm/acpi.h | 5 +
drivers/acpi/apei/hest.c | 19 ---
3 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 871f217..58c8992 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -3,6 +3,7 @@ config ARM64
select ACPI_CCA_REQUIRED if ACPI
select ACPI_GENERIC_GSI if ACPI
select ACPI_REDUCED_HARDWARE_ONLY if ACPI
+ select HAVE_ACPI_APEI if ACPI
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_GCOV_PROFILE_ALL
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index caafd63..31d3d9a 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -17,6 +17,7 @@
#include
#include
+#include
/* Macros for consistency checks of the GICC subtable of MADT */
#define ACPI_MADT_GICC_LENGTH \
@@ -94,6 +95,10 @@ static inline const char *acpi_get_enable_method(int cpu)
#ifdef CONFIG_ACPI_APEI
pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr);
+static inline void arch_apei_flush_tlb_one(unsigned long addr)
+{
+ flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
+}
#endif
#endif /*_ASM_ACPI_H*/
diff --git a/drivers/acpi/apei/hest.c b/drivers/acpi/apei/hest.c
index 20b3fcf..715c58b 100644
--- a/drivers/acpi/apei/hest.c
+++ b/drivers/acpi/apei/hest.c
@@ -117,15 +117,27 @@ int apei_hest_parse(apei_hest_func_t func, void *data)
}
EXPORT_SYMBOL_GPL(apei_hest_parse);
+#if defined(__i386__) || defined(__x86_64__)
/*
* Check if firmware advertises firmware first mode. We need FF bit to be set
* along with a set of MC banks which work in FF mode.
*/
static int __init hest_parse_cmc(struct acpi_hest_header *hest_hdr, void *data)
{
- return arch_apei_enable_cmcff(hest_hdr, data);
+ if (!acpi_disable_cmcff)
+ return !arch_apei_enable_cmcff(hest_hdr, data);
+
+ return 0;
}
+static inline int __init hest_ia_init(void)
+{
+ return apei_hest_parse(hest_parse_cmc, NULL);
+}
+#else
+static inline int __init hest_ia_init(void) { return 0; }
+#endif
+
struct ghes_arr {
struct platform_device **ghes_devs;
unsigned int count;
@@ -232,8 +244,9 @@ void __init acpi_hest_init(void)
goto err;
}
- if (!acpi_disable_cmcff)
- apei_hest_parse(hest_parse_cmc, NULL);
+ rc = hest_ia_init();
+ if (rc)
+ goto err;
if (!ghes_disable) {
rc = apei_hest_parse(hest_parse_ghes_count, _count);
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: An issue about sp5100 watchdog
On 12/07/2015 09:42 PM, Huang Rui wrote: Hi all, I found an issue in some of AMD platforms about sp5100, that the MMIO address (0x51413120) is already used by System RAM (0010-7c2befff)... [ 29.928096] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver v0.05 [ 29.928302] sp5100_tco: PCI Vendor ID: 0x1022, Device ID: 0x790b, Revision ID: 0x4a [ 29.928319] sp5100_tco: Got 0x51413120 from indirect I/O [ 29.928323] sp5100_tco: MMIO address 0x51413120 already in use [ 29.928332] sp5100_tco: SBResource_MMIO is disabled(0xe000a0) [ 29.928333] sp5100_tco: failed to find MMIO address, giving up. If I understand the code correctly, the problem is really "SBResource_MMIO is disabled". Presumably that is done in the BIOS. No idea if anything can be done about that. Guenter 0010-7c2befff : System RAM 0100-017b1ab3 : Kernel code 017b1ab4-01d4ce7f : Kernel data 01ec4000-02008fff : Kernel bss 7c2bf000-7c8befff : reserved 7c8bf000-7cbbefff : ACPI Non-volatile Storage 7cbb6000-7cbb9fff : MSFT0101:00 7cbba000-7cbbdfff : MSFT0101:00 7cbbf000-7cbfefff : ACPI Tables 7cbff000-7cbf : System RAM 7cc0-7eff : reserved Any idea? Thanks, Rui -- To unsubscribe from this list: send the line "unsubscribe linux-watchdog" 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 00/12] x86: Rewrite 64-bit syscall code
* Andy Lutomirski wrote: > On Mon, Dec 7, 2015 at 8:42 PM, Ingo Molnar wrote: > > > > * Andy Lutomirski wrote: > > > >> On Mon, Dec 7, 2015 at 1:51 PM, Andy Lutomirski wrote: > >> > >> > This is kind of like the 32-bit and compat code, except that I preserved > >> > the > >> > fast path this time. I was unable to measure any significant performance > >> > change on my laptop in the fast path. > >> > > >> > What do you all think? > >> > >> For completeness, if I zap the fast path entirely (see attached), I lose 20 > >> cycles (148 cycles vs 128 cycles) on Skylake. Switching between movq and > >> pushq > >> for stack setup makes no difference whatsoever, interestingly. I haven't > >> tried > >> to figure out exactly where those 20 cycles go. > > > > So I asked for this before, and I'll do so again: could you please stick > > the cycle > > granular system call performance test into a 'perf bench' variant so that: > > > > 1) More people can run it all on various pieces of hardware and help out > > quantify > > the patches. > > > > 2) We can keep an eye on not regressing base system call performance in the > > future, with a good in-tree testcase. > > > > Is it okay if it's not particularly shiny or modular? [...] Absolutely! > [...] The tool I'm using is here: > > https://git.kernel.org/cgit/linux/kernel/git/luto/misc-tests.git/tree/tight_loop/perf_self_monitor.c > > and I can certainly stick it into 'perf bench' pretty easily. Can I > leave making it into a proper library to some future contributor? Sure - 'perf bench' tests aren't librarized generally - the goal is to make it easy to create a new measurement. > It's actually decently fancy. It allocates a perf self-monitoring > instance that counts cycles, and then it takes a bunch of samples and > discards any that flagged a context switch. It does some very > rudimentary statistics on the rest. It's utterly devoid of a fancy > UI, though. > > It works very well on native, and it works better than I had expected > under KVM. (KVM traps RDPMC because neither Intel nor AMD has seen > fit to provide any sensible way to virtualize RDPMC without exiting.) Sounds fantastic to me! 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][experimantal] cpufreq: governor: Use an atomic variable for synchronization
On 08-12-15, 01:39, Rafael J. Wysocki wrote:
> @@ -269,9 +259,6 @@ static void dbs_timer_handler(unsigned l
> {
> struct cpu_dbs_info *cdbs = (struct cpu_dbs_info *)data;
> struct cpu_common_dbs_info *shared = cdbs->shared;
> - unsigned long flags;
> -
> - spin_lock_irqsave(>timer_lock, flags);
>
> /*
>* Timer handler isn't allowed to queue work at the moment, because:
> @@ -279,12 +266,10 @@ static void dbs_timer_handler(unsigned l
>* - We are stopping the governor
>* - Or we are updating the sampling rate of ondemand governor
>*/
> - if (!shared->skip_work) {
> - shared->skip_work++;
> + if (atomic_inc_return(>skip_work) > 1)
> + atomic_dec(>skip_work);
> + else
> queue_work(system_wq, >work);
> - }
As explained in the other email, this is wrong..
--
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/
Re: [PATCH net-next] net: hns: optimize XGE capability by reducing cpu usage
On 2015/12/8 14:30, Du, Fan wrote: > > > On 2015/12/8 14:22, Yankejian (Hackim Yim) wrote: >> >> On 2015/12/7 16:58, Du, Fan wrote: >>> > >>> > >>> >On 2015/12/5 15:32, yankejian wrote: >>here is the patch raising the performance of XGE by: >>1)changes the way page management method for enet momery, and >>2)reduces the count of rmb, and >>3)adds Memory prefetching >>> > >>> >Any numbers on how much it boost performance? >>> > >> it is almost the same as 82599. > > I mean how much it improves performance *BEFORE* and *AFTER* this patch > for Huawei XGE chip, because the commit log states it "raising the > performance", > but did give numbers of the testing. > > . > Hi Du Fan, the bandwidth's raising is not obviously, but the cpu usage degracing up to 50% -- 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 5/6] cpufreq: governor: replace per-cpu delayed work with timers
On 07-12-15, 23:43, Rafael J. Wysocki wrote: > On Monday, December 07, 2015 01:20:27 PM Viresh Kumar wrote: > > At this point we might end up decrementing skip_work from > > gov_cancel_work() and then cancel the work which we haven't queued > > yet. And the end result will be that the work is still queued while > > gov_cancel_work() has finished. > > I'm not quite sure how that can happen. I will describe that towards the end of this email. > There is a bug in this code snippet, but it may cause us to fail to queue > the work at all, so the incrementation and the check need to be done > under the spinlock. What bug ? > > And we have to keep the atomic operation, as well as queue_work() > > within the lock. > > Putting queue_work() under the lock doesn't prevent any races from happening, Then I am not able to think about it properly, but I will at least present my case here :) > because only one of the CPUs can execute that part of the function anyway. > > > > queue_work(system_wq, >work); > > > > > > and the remaining incrementation and decrementation of skip_work are > > > replaced > > > with the corresponding atomic operations, it still should work, no? > > Well, no, the above wouldn't work. > > But what about something like this instead: > > if (atomic_inc_return(>skip_work) > 1) > atomic_dec(>skip_work); > else > queue_work(system_wq, >work); > > (plus the changes requisite replacements in the other places)? > > Only one CPU can see the result of the atomic_inc_return() as 1 and this is > the > only one that will queue up the work item, unless I'm missing anything super > subtle. Looks like you are talking about the race between different timer handlers, which race against queuing the work. Sorry if you are not. But I am not talking about that thing.. Suppose queue_work() isn't done within the spin lock. CPU0CPU1 cpufreq_governor_stop() dbs_timer_handler() -> gov_cancel_work()-> lock -> shared->skip_work++, as skip_work was 0. //skip_work=1 -> unlock -> lock -> shared->skip_work++; //skip_work=2 -> unlock -> cancel_work_sync(>work); -> queue_work(); -> gov_cancel_timers(shared->policy); -> shared->skip_work = 0; dbs_work_handler(); And according to how I understand it, we are screwed up at this point. And its the same old bug which I fixed recently (which we hacked up by using gov-lock earlier). The work handler is still active after the policy-governor is stopped. And your latest patch looks wrong for the same reason ... -- 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/
Re: [RFC 0/3] reduce latency of direct async compaction
On Tue, Dec 08, 2015 at 01:14:39PM +0800, Aaron Lu wrote:
> On Tue, Dec 08, 2015 at 09:41:18AM +0900, Joonsoo Kim wrote:
> > On Mon, Dec 07, 2015 at 04:59:56PM +0800, Aaron Lu wrote:
> > > On Mon, Dec 07, 2015 at 04:35:24PM +0900, Joonsoo Kim wrote:
> > > > It looks like overhead still remain. I guess that migration scanner
> > > > would call pageblock_pfn_to_page() for more extended range so
> > > > overhead still remain.
> > > >
> > > > I have an idea to solve his problem. Aaron, could you test following
> > > > patch
> > > > on top of base? It tries to skip calling pageblock_pfn_to_page()
> > >
> > > It doesn't apply on top of 25364a9e54fb8296837061bf684b76d20eec01fb
> > > cleanly, so I made some changes to make it apply and the result is:
> > > https://github.com/aaronlu/linux/commit/cb8d05829190b806ad3948ff9b9e08c8ba1daf63
> >
> > Yes, that's okay. I made it on my working branch but it will not result in
> > any problem except applying.
> >
> > >
> > > There is a problem occured right after the test starts:
> > > [ 58.080962] BUG: unable to handle kernel paging request at
> > > ea008218
> > > [ 58.089124] IP: [] compaction_alloc+0xf9/0x270
> > > [ 58.096109] PGD 107ffd6067 PUD 207f7d5067 PMD 0
> > > [ 58.101569] Oops: [#1] SMP
> >
> > I did some mistake. Please test following patch. It is also made
> > on my working branch so you need to resolve conflict but it would be
> > trivial.
> >
> > I inserted some logs to check whether zone is contiguous or not.
> > Please check that normal zone is set to contiguous after testing.
>
> Yes it is contiguous, but unfortunately, the problem remains:
> [ 56.536930] check_zone_contiguous: Normal
> [ 56.543467] check_zone_contiguous: Normal: contiguous
> [ 56.549640] BUG: unable to handle kernel paging request at ea008218
> [ 56.557717] IP: [] compaction_alloc+0xf9/0x270
> [ 56.564719] PGD 107ffd6067 PUD 207f7d5067 PMD 0
>
Maybe, I find the reason. cc->free_pfn can be initialized to invalid pfn
that isn't checked so optimized pageblock_pfn_to_page() causes BUG().
I add work-around for this problem at isolate_freepages(). Please test
following one.
Thanks.
-->8---
>From 7e954a68fb555a868acc5860627a1ad8dadbe3bf Mon Sep 17 00:00:00 2001
From: Joonsoo Kim
Date: Mon, 7 Dec 2015 14:51:42 +0900
Subject: [PATCH] mm/compaction: Optimize pageblock_pfn_to_page() for
contiguous zone
Signed-off-by: Joonsoo Kim
---
include/linux/mmzone.h | 1 +
mm/compaction.c| 60 +-
2 files changed, 60 insertions(+), 1 deletion(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index e23a9e7..573f9a9 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -521,6 +521,7 @@ struct zone {
#endif
#if defined CONFIG_COMPACTION || defined CONFIG_CMA
+ int contiguous;
/* Set to true when the PG_migrate_skip bits should be cleared */
boolcompact_blockskip_flush;
#endif
diff --git a/mm/compaction.c b/mm/compaction.c
index de3e1e7..ff5fb04 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -88,7 +88,7 @@ static inline bool migrate_async_suitable(int migratetype)
* the first and last page of a pageblock and avoid checking each individual
* page in a pageblock.
*/
-static struct page *pageblock_pfn_to_page(unsigned long start_pfn,
+static struct page *__pageblock_pfn_to_page(unsigned long start_pfn,
unsigned long end_pfn, struct zone *zone)
{
struct page *start_page;
@@ -114,6 +114,56 @@ static struct page *pageblock_pfn_to_page(unsigned long
start_pfn,
return start_page;
}
+static inline struct page *pageblock_pfn_to_page(unsigned long start_pfn,
+ unsigned long end_pfn, struct zone *zone)
+{
+ if (zone->contiguous == 1)
+ return pfn_to_page(start_pfn);
+
+ return __pageblock_pfn_to_page(start_pfn, end_pfn, zone);
+}
+
+static void check_zone_contiguous(struct zone *zone)
+{
+ unsigned long block_start_pfn = zone->zone_start_pfn;
+ unsigned long block_end_pfn;
+ unsigned long pfn;
+
+ /* Already checked */
+ if (zone->contiguous)
+ return;
+
+ printk("%s: %s\n", __func__, zone->name);
+ block_end_pfn = ALIGN(block_start_pfn + 1, pageblock_nr_pages);
+ for (; block_start_pfn < zone_end_pfn(zone);
+ block_start_pfn = block_end_pfn,
+ block_end_pfn += pageblock_nr_pages) {
+
+ block_end_pfn = min(block_end_pfn, zone_end_pfn(zone));
+
+ if (!__pageblock_pfn_to_page(block_start_pfn,
+ block_end_pfn, zone)) {
+ /* We have hole */
+ zone->contiguous = -1;
+ printk("%s: %s: uncontiguous\n", __func__, zone->name);
+ return;
+
Re: [PATCH v4 1/8] ARM: dts: Exynos542x/5800: add cluster regulator supply properties
On 08.12.2015 03:18, Bartlomiej Zolnierkiewicz wrote:
> Add cluster regulator supply properties as a preparation to
> adding generic cpufreq-dt driver support for Exynos542x and
> Exynos5800 based boards.
>
> Cc: Kukjin Kim
> Cc: Doug Anderson
> Cc: Javier Martinez Canillas
That's Javier's old email, not working any more. I think he same applies
to Mike's in CC-list.
> Cc: Andreas Faerber
> Cc: Sachin Kamat
> Cc: Thomas Abraham
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> arch/arm/boot/dts/exynos5420-arndale-octa.dts | 8
> arch/arm/boot/dts/exynos5420-peach-pit.dts | 8
> arch/arm/boot/dts/exynos5420-smdk5420.dts | 8
> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 8
> arch/arm/boot/dts/exynos5422-odroidxu3.dts | 8
> arch/arm/boot/dts/exynos5422-odroidxu4.dts | 8
> arch/arm/boot/dts/exynos5800-peach-pi.dts | 8
> 7 files changed, 56 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> index 4ecef69..4229641 100644
> --- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> +++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> @@ -52,6 +52,14 @@
> };
> };
>
> + {
> + cpu-supply = <_reg>;
> +};
> +
> + {
> + cpu-supply = <_reg>;
> +};
> +
> _dwc3_1 {
> dr_mode = "host";
> };
> diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
> b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> index 35cfb07..30f146b 100644
> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> @@ -676,6 +676,14 @@
> };
> };
>
> + {
> + cpu-supply = <_reg>;
> +};
> +
> + {
> + cpu-supply = <_reg>;
> +};
> +
> _2 {
> status = "okay";
> samsung,i2c-sda-delay = <100>;
> diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
> b/arch/arm/boot/dts/exynos5420-smdk5420.dts
> index ac35aef..fdfe4e6 100644
> --- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
> +++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
> @@ -423,3 +423,11 @@
> _phy1 {
> vbus-supply = <_vbus_reg>;
> };
> +
> + {
> + cpu-supply = <_reg>;
> +};
> +
> + {
> + cpu-supply = <_reg>;
> +};
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> index 2ae1cf4..0bfd981 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> @@ -54,6 +54,14 @@
> };
> };
>
> + {
> + cpu-supply = <_reg>;
> +};
> +
> + {
> + cpu-supply = <_reg>;
> +};
> +
> {
> /*
>* PWM 0 -- fan
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> index 432406d..b19561c 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> @@ -53,6 +53,14 @@
> };
> };
>
> + {
> + cpu-supply = <_reg>;
> +};
> +
> + {
> + cpu-supply = <_reg>;
> +};
> +
> _0 {
> status = "okay";
>
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> index 2faf886..bdc7106 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> @@ -32,6 +32,14 @@
> };
> };
>
> + {
> + cpu-supply = <_reg>;
> +};
> +
> + {
> + cpu-supply = <_reg>;
> +};
> +
How about putting these Odroid changes in exynos5422-odroidxu3-common.dtsi?
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 5/6] cpufreq: governor: replace per-cpu delayed work with timers
On 08-12-15, 00:17, Rafael J. Wysocki wrote: > In fact, I've already folded the above changes into the $subject patch (but > this > is an exception). Yeah I know, I would have sent a patch this morning though. -- 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 v6 3/8] spi: imx: return error from dma channel request
On SDMA initialization return exactly the same error, which is
reported by dma_request_slave_channel_reason(), it is a preceding
change to defer SPI DMA initialization, if SDMA module is not yet
available.
Signed-off-by: Vladimir Zapolskiy
Signed-off-by: Anton Bondarenko
---
drivers/spi/spi-imx.c | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 17a90dc..c123060 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -848,10 +848,11 @@ static int spi_imx_sdma_init(struct device *dev, struct
spi_imx_data *spi_imx,
spi_imx->wml = spi_imx_get_fifosize(spi_imx) / 2;
/* Prepare for TX DMA: */
- master->dma_tx = dma_request_slave_channel(dev, "tx");
- if (!master->dma_tx) {
- dev_err(dev, "cannot get the TX DMA channel!\n");
- ret = -EINVAL;
+ master->dma_tx = dma_request_slave_channel_reason(dev, "tx");
+ if (IS_ERR(master->dma_tx)) {
+ ret = PTR_ERR(master->dma_tx);
+ dev_dbg(dev, "can't get the TX DMA channel, error %d!\n", ret);
+ master->dma_tx = NULL;
goto err;
}
@@ -866,10 +867,11 @@ static int spi_imx_sdma_init(struct device *dev, struct
spi_imx_data *spi_imx,
}
/* Prepare for RX : */
- master->dma_rx = dma_request_slave_channel(dev, "rx");
- if (!master->dma_rx) {
- dev_dbg(dev, "cannot get the DMA channel.\n");
- ret = -EINVAL;
+ master->dma_rx = dma_request_slave_channel_reason(dev, "rx");
+ if (IS_ERR(master->dma_rx)) {
+ ret = PTR_ERR(master->dma_rx);
+ dev_dbg(dev, "can't get the RX DMA channel, error %d\n", ret);
+ master->dma_rx = NULL;
goto err;
}
@@ -1218,9 +1220,12 @@ static int spi_imx_probe(struct platform_device *pdev)
* Only validated on i.mx6 now, can remove the constrain if validated on
* other chips.
*/
- if (is_imx51_ecspi(spi_imx) &&
- spi_imx_sdma_init(>dev, spi_imx, master, res))
- dev_err(>dev, "dma setup error,use pio instead\n");
+ if (is_imx51_ecspi(spi_imx)) {
+ ret = spi_imx_sdma_init(>dev, spi_imx, master, res);
+ if (ret < 0)
+ dev_err(>dev, "dma setup error %d, use pio\n",
+ ret);
+ }
spi_imx->devtype_data->reset(spi_imx);
--
2.6.3
--
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 v6 1/8] spi: imx: fix loopback mode setup after controller reset
If controller hold in reset it's not possible to write any register except CTRL. So all other registers must be updated only after controller bring out from reset. Signed-off-by: Anton Bondarenko --- drivers/spi/spi-imx.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c index 410522f..3aa33c8 100644 --- a/drivers/spi/spi-imx.c +++ b/drivers/spi/spi-imx.c @@ -356,6 +356,9 @@ static int __maybe_unused mx51_ecspi_config(struct spi_imx_data *spi_imx, else cfg &= ~MX51_ECSPI_CONFIG_SSBPOL(config->cs); + /* CTRL register always go first to bring out controller from reset */ + writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL); + reg = readl(spi_imx->base + MX51_ECSPI_TESTREG); if (config->mode & SPI_LOOP) reg |= MX51_ECSPI_TESTREG_LBC; @@ -363,7 +366,6 @@ static int __maybe_unused mx51_ecspi_config(struct spi_imx_data *spi_imx, reg &= ~MX51_ECSPI_TESTREG_LBC; writel(reg, spi_imx->base + MX51_ECSPI_TESTREG); - writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL); writel(cfg, spi_imx->base + MX51_ECSPI_CONFIG); /* -- 2.6.3 -- 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 v6 4/8] spi: imx: defer spi initialization, if DMA engine is
If SPI device supports DMA mode, but DMA controller is not yet
available due to e.g. a delay in the corresponding kernel module
initialization, retry to initialize SPI driver later on instead of
falling back into PIO only mode.
Signed-off-by: Anton Bondarenko
---
drivers/spi/spi-imx.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index c123060..d98c33c 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -1222,6 +1222,9 @@ static int spi_imx_probe(struct platform_device *pdev)
*/
if (is_imx51_ecspi(spi_imx)) {
ret = spi_imx_sdma_init(>dev, spi_imx, master, res);
+ if (ret == -EPROBE_DEFER)
+ goto out_clk_put;
+
if (ret < 0)
dev_err(>dev, "dma setup error %d, use pio\n",
ret);
--
2.6.3
--
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 linux-next 0/5] mtd: spi-nor: add driver for Atmel QSPI controller
> > I'll admit I'm a little fuzzy on the differences between dual and quad modes > on > various flash manufacturers. Can you help clear it up for me? For SPI NOR, currently, don't have an official standard to define an uniform Quad I/O mode protocol. So we can see that there are some difference between Flash Vendor.
[PATCH v6 5/8] spi: imx: allow only WML aligned transfers to use DMA
RX DMA tail data handling doesn't work correctly in many cases with current
implementation. It happens because SPI core was setup to generates both RX
and RX TAIL events. And RX TAIL event does not work correctly.
This can be easily verified by sending SPI transaction with size modulus
WML(32 in our case) not equal 0.
Also removing change introduced in f6ee9b582d2db652497b73c1f117591dfb6d3a90
since this change only fix usecases with transfer size from 33 to 128 bytes
and doesn't fix 129 bytes and bigger.
This is output from transaction with len 138 bytes in loopback mode at 10Mhz:
TX: a3 97 a2 55 53 be f1 fc f9 79 6b 52 14 13 e9 e2
TX0010: 2d 51 8e 1f 56 08 57 27 a7 05 d4 d0 52 82 77 75
TX0020: 1b 99 4a ed 58 3d 6a 52 36 d5 24 4a 68 8e ad 95
TX0030: 5f 3c 35 b5 c4 8c dd 6c 11 32 3d e2 b4 b4 59 cf
TX0040: ce 23 3d 27 df a7 f9 96 fc 1e e0 66 2c 0e 7b 8c
TX0050: ca 30 42 8f bc 9f 7b ce d1 b8 b1 87 ec 8a d6 bb
TX0060: 2e 15 63 0e 3c dc a4 3a 7a 06 20 a7 93 1b 34 dd
TX0070: 4c f5 ec 88 96 68 d6 68 a0 09 6f 8e 93 47 c9 41
TX0080: db ac cf 97 89 f3 51 05 79 71
RX: a3 97 a2 55 53 be f1 fc f9 79 6b 52 14 13 e9 e2
RX0010: 2d 51 8e 1f 56 08 57 27 a7 05 d4 d0 52 82 77 75
RX0020: 1b 99 4a ed 58 3d 6a 52 36 d5 24 4a 68 8e ad 95
RX0030: 5f 3c 35 00 00 b5 00 00 00 c4 00 00 8c 00 00 dd
RX0040: 6c 11 32 3d e2 b4 b4 59 cf ce 23 3d 27 df a7 f9
RX0050: 96 fc 1e e0 66 2c 0e 7b 8c ca 30 42 8f 1f 1f bc
RX0060: 9f 7b ce d1 b8 b1 87 ec 8a d6 bb 2e 15 63 0e ed
RX0070: ed 3c 58 58 58 dc 3d 3d a4 6a 6a 3a 52 52 7a 36
RX0080: 06 20 a7 93 1b 34 dd 4c f5 ec
Zeros at offset 33 and 34 caused by reading empty RX FIFO which not possible
if DMA RX read was triggered by RX event. This mean DMA was triggered
by RX TAIL event.
Signed-off-by: Anton Bondarenko
---
drivers/spi/spi-imx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index d98c33c..50e0a79 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -204,8 +204,8 @@ static bool spi_imx_can_dma(struct spi_master *master,
struct spi_device *spi,
{
struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
- if (spi_imx->dma_is_inited &&
- transfer->len > spi_imx->wml * sizeof(u32))
+ if (spi_imx->dma_is_inited && transfer->len >= spi_imx->wml &&
+ (transfer->len % spi_imx->wml) == 0)
return true;
return false;
}
--
2.6.3
--
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 v6 8/8] spi: imx: add support for all SPI word width for DMA
DMA transfer for SPI was limited to up to 8 bits word size until now.
Sync in SPI burst size and DMA bus width is necessary to correctly
support 16 and 32 BPW.
Signed-off-by: Anton Bondarenko
---
drivers/spi/spi-imx.c | 121 +++---
1 file changed, 95 insertions(+), 26 deletions(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index d74d809..750001c 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -88,11 +88,15 @@ struct spi_imx_data {
struct completion xfer_done;
void __iomem *base;
+ unsigned long base_phys;
+
struct clk *clk_per;
struct clk *clk_ipg;
unsigned long spi_clk;
unsigned int spi_bus_clk;
+ unsigned int bytes_per_word;
+
unsigned int count;
void (*tx)(struct spi_imx_data *);
void (*rx)(struct spi_imx_data *);
@@ -199,13 +203,32 @@ static unsigned int spi_imx_clkdiv_2(unsigned int fin,
return 7;
}
+static int spi_imx_get_bytes_per_word(const int bpw)
+{
+ return DIV_ROUND_UP(bpw, BITS_PER_BYTE);
+}
+
static bool spi_imx_can_dma(struct spi_master *master, struct spi_device *spi,
struct spi_transfer *transfer)
{
struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
+ unsigned int bpw = transfer->bits_per_word;
+
+ if (!bpw)
+ bpw = spi->bits_per_word;
- if (spi_imx->dma_is_inited && transfer->len >= spi_imx->wml &&
- (transfer->len % spi_imx->wml) == 0)
+ bpw = spi_imx_get_bytes_per_word(bpw);
+
+ /*
+* We need to use SPI word size in calculation to decide
+* if we want to go with DMA or PIO mode. Just a short example:
+* We need to transfer 24 SPI words with BPW == 32. This will take
+* 24 PIO writes to FIFO (and same for reads). But transfer->len will
+* be 24*4=96 bytes. WML is 32 SPI words. The decision will be incorrect
+* if we do not take into account SPI bits per word.
+*/
+ if (spi_imx->dma_is_inited && transfer->len >= (spi_imx->wml * bpw) &&
+ (transfer->len % (spi_imx->wml * bpw)) == 0)
return true;
return false;
}
@@ -785,11 +808,60 @@ static irqreturn_t spi_imx_isr(int irq, void *dev_id)
return IRQ_HANDLED;
}
+static int spi_imx_sdma_configure(struct spi_master *master)
+{
+ int ret;
+ enum dma_slave_buswidth dsb_default = DMA_SLAVE_BUSWIDTH_1_BYTE;
+ struct dma_slave_config slave_config = {};
+ struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
+
+ switch (spi_imx->bytes_per_word) {
+ case 4:
+ dsb_default = DMA_SLAVE_BUSWIDTH_4_BYTES;
+ break;
+ case 2:
+ dsb_default = DMA_SLAVE_BUSWIDTH_2_BYTES;
+ break;
+ case 1:
+ dsb_default = DMA_SLAVE_BUSWIDTH_1_BYTE;
+ break;
+ default:
+ pr_err("Not supported word size %d\n", spi_imx->bytes_per_word);
+ ret = -EINVAL;
+ goto err;
+ }
+
+ slave_config.direction = DMA_MEM_TO_DEV;
+ slave_config.dst_addr = spi_imx->base_phys + MXC_CSPITXDATA;
+ slave_config.dst_addr_width = dsb_default;
+ slave_config.dst_maxburst = spi_imx->wml;
+ ret = dmaengine_slave_config(master->dma_tx, _config);
+ if (ret) {
+ pr_err("error in TX dma configuration.\n");
+ goto err;
+ }
+
+ memset(_config, 0, sizeof(slave_config));
+
+ slave_config.direction = DMA_DEV_TO_MEM;
+ slave_config.src_addr = spi_imx->base_phys + MXC_CSPIRXDATA;
+ slave_config.src_addr_width = dsb_default;
+ slave_config.src_maxburst = spi_imx->wml;
+ ret = dmaengine_slave_config(master->dma_rx, _config);
+ if (ret)
+ pr_err("error in RX dma configuration.\n");
+
+err:
+ return ret;
+}
+
static int spi_imx_setupxfer(struct spi_device *spi,
struct spi_transfer *t)
{
struct spi_imx_data *spi_imx = spi_master_get_devdata(spi->master);
struct spi_imx_config config;
+ unsigned int new_bytes_per_word;
+ int ret = 0;
config.bpw = t ? t->bits_per_word : spi->bits_per_word;
config.speed_hz = t ? t->speed_hz : spi->max_speed_hz;
@@ -813,9 +885,19 @@ static int spi_imx_setupxfer(struct spi_device *spi,
spi_imx->tx = spi_imx_buf_tx_u32;
}
- spi_imx->devtype_data->config(spi_imx, );
+ new_bytes_per_word = spi_imx_get_bytes_per_word(config.bpw);
+ if (spi_imx->dma_is_inited &&
+ spi_imx->bytes_per_word != new_bytes_per_word) {
+ spi_imx->bytes_per_word = new_bytes_per_word;
+ ret = spi_imx_sdma_configure(spi->master);
+ if (ret != 0)
+ pr_err("Can't configure SDMA, error %d\n", ret);
+ }
-
[PATCH v6 0/8] Improvements for SPI IMX driver for Freescale ECSPI controller, continuation
This series is to complement commits already applied to topic/imx branch Changes since V5: * Fix for commit "spi: imx: Add loopback mode support" * Addressed some comments from Sascha Hauer for DMA initialization error report * Fixed 32 bytes transaction. It will be DMA now. Anton Bondarenko (8): spi: imx: fix loopback mode setup after controller reset spi: imx: enable loopback only for ECSPI controller family spi: imx: return error from dma channel request spi: imx: defer spi initialization, if DMA engine is spi: imx: allow only WML aligned transfers to use DMA spi: imx: remove dead RX DMA tail handling code spi: imx: replace fixed timeout with calculated spi: imx: add support for all SPI word width for DMA drivers/spi/spi-imx.c | 203 +++--- 1 file changed, 145 insertions(+), 58 deletions(-) -- 2.6.3 -- 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 v6 7/8] spi: imx: replace fixed timeout with calculated
Fixed timeout value can fire while transaction is ongoing. This may happen
because there are no strict requirements on SPI transaction duration.
Dynamic timeout value is generated based on SCLK and transaction size.
There is also 4 * SCLK delay between TX bursts related to HW internal CS change.
Signed-off-by: Anton Bondarenko
---
drivers/spi/spi-imx.c | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 08492d6..d74d809 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -56,7 +56,6 @@
/* The maximum bytes that a sdma BD can transfer.*/
#define MAX_SDMA_BD_BYTES (1 << 15)
-#define IMX_DMA_TIMEOUT (msecs_to_jiffies(3000))
struct spi_imx_config {
unsigned int speed_hz;
unsigned int bpw;
@@ -92,6 +91,7 @@ struct spi_imx_data {
struct clk *clk_per;
struct clk *clk_ipg;
unsigned long spi_clk;
+ unsigned int spi_bus_clk;
unsigned int count;
void (*tx)(struct spi_imx_data *);
@@ -331,6 +331,7 @@ static int __maybe_unused mx51_ecspi_config(struct
spi_imx_data *spi_imx,
/* set clock speed */
ctrl |= mx51_ecspi_clkdiv(spi_imx->spi_clk, config->speed_hz, );
+ spi_imx->spi_bus_clk = clk;
/* set chip select to use */
ctrl |= MX51_ECSPI_CTRL_CS(config->cs);
@@ -913,11 +914,26 @@ static void spi_imx_dma_tx_callback(void *cookie)
complete(_imx->dma_tx_completion);
}
+static int spi_imx_calculate_timeout(struct spi_imx_data *spi_imx, int size)
+{
+ unsigned long timeout = 0;
+
+ /* Time with actual data transfer and CS change delay related to HW */
+ timeout = (8 + 4) * size / spi_imx->spi_bus_clk;
+
+ /* Add extra second for scheduler related activities */
+ timeout += 1;
+
+ /* Double calculated timeout */
+ return msecs_to_jiffies(2 * timeout * MSEC_PER_SEC);
+}
+
static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
struct spi_transfer *transfer)
{
struct dma_async_tx_descriptor *desc_tx = NULL, *desc_rx = NULL;
int ret;
+ unsigned long transfer_timeout;
unsigned long timeout;
struct spi_master *master = spi_imx->bitbang.master;
struct sg_table *tx = >tx_sg, *rx = >rx_sg;
@@ -964,9 +980,11 @@ static int spi_imx_dma_transfer(struct spi_imx_data
*spi_imx,
dma_async_issue_pending(master->dma_tx);
spi_imx->devtype_data->trigger(spi_imx);
+ transfer_timeout = spi_imx_calculate_timeout(spi_imx, transfer->len);
+
/* Wait SDMA to finish the data transfer.*/
timeout = wait_for_completion_timeout(_imx->dma_tx_completion,
- IMX_DMA_TIMEOUT);
+ transfer_timeout);
if (!timeout) {
pr_warn("%s %s: I/O Error in DMA TX\n",
dev_driver_string(>dev),
@@ -974,8 +992,10 @@ static int spi_imx_dma_transfer(struct spi_imx_data
*spi_imx,
dmaengine_terminate_all(master->dma_tx);
dmaengine_terminate_all(master->dma_rx);
} else {
+ transfer_timeout = spi_imx_calculate_timeout(spi_imx,
+spi_imx->wml);
timeout = wait_for_completion_timeout(
- _imx->dma_rx_completion, IMX_DMA_TIMEOUT);
+ _imx->dma_rx_completion, transfer_timeout);
if (!timeout) {
pr_warn("%s %s: I/O Error in DMA RX\n",
dev_driver_string(>dev),
--
2.6.3
--
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 v6 2/8] spi: imx: enable loopback only for ECSPI controller family
Limit SPI_LOOP mode to ECSPI controller (iMX.51, iMX53 and i.MX6) only since
there is no support in other families specific code for now.
Signed-off-by: Anton Bondarenko
---
drivers/spi/spi-imx.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 3aa33c8..17a90dc 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -1140,6 +1140,9 @@ static int spi_imx_probe(struct platform_device *pdev)
spi_imx = spi_master_get_devdata(master);
spi_imx->bitbang.master = master;
+ spi_imx->devtype_data = of_id ? of_id->data :
+ (struct spi_imx_devtype_data *)pdev->id_entry->driver_data;
+
for (i = 0; i < master->num_chipselect; i++) {
int cs_gpio = of_get_named_gpio(np, "cs-gpios", i);
if (!gpio_is_valid(cs_gpio) && mxc_platform_info)
@@ -1164,14 +1167,12 @@ static int spi_imx_probe(struct platform_device *pdev)
spi_imx->bitbang.master->cleanup = spi_imx_cleanup;
spi_imx->bitbang.master->prepare_message = spi_imx_prepare_message;
spi_imx->bitbang.master->unprepare_message = spi_imx_unprepare_message;
- spi_imx->bitbang.master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH |
-SPI_LOOP;
+ spi_imx->bitbang.master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH;
+ if (is_imx51_ecspi(spi_imx))
+ spi_imx->bitbang.master->mode_bits |= SPI_LOOP;
init_completion(_imx->xfer_done);
- spi_imx->devtype_data = of_id ? of_id->data :
- (struct spi_imx_devtype_data *) pdev->id_entry->driver_data;
-
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
spi_imx->base = devm_ioremap_resource(>dev, res);
if (IS_ERR(spi_imx->base)) {
--
2.6.3
--
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 v6 6/8] spi: imx: remove dead RX DMA tail handling code
transfer->len % wml for DMA capable transactions will always be 0 due to recent change in can_dma checks. So it's safe to remove dead code in processing DMA. Signed-off-by: Anton Bondarenko --- drivers/spi/spi-imx.c | 13 - 1 file changed, 13 deletions(-) diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c index 50e0a79..08492d6 100644 --- a/drivers/spi/spi-imx.c +++ b/drivers/spi/spi-imx.c @@ -919,8 +919,6 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx, struct dma_async_tx_descriptor *desc_tx = NULL, *desc_rx = NULL; int ret; unsigned long timeout; - u32 dma; - int left; struct spi_master *master = spi_imx->bitbang.master; struct sg_table *tx = >tx_sg, *rx = >rx_sg; @@ -954,13 +952,6 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx, /* Trigger the cspi module. */ spi_imx->dma_finished = 0; - dma = readl(spi_imx->base + MX51_ECSPI_DMA); - dma = dma & (~MX51_ECSPI_DMA_RXT_WML_MASK); - /* Change RX_DMA_LENGTH trigger dma fetch tail data */ - left = transfer->len % spi_imx->wml; - if (left) - writel(dma | (left << MX51_ECSPI_DMA_RXT_WML_OFFSET), - spi_imx->base + MX51_ECSPI_DMA); /* * Set these order to avoid potential RX overflow. The overflow may * happen if we enable SPI HW before starting RX DMA due to rescheduling @@ -992,10 +983,6 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx, spi_imx->devtype_data->reset(spi_imx); dmaengine_terminate_all(master->dma_rx); } - dma &= ~MX51_ECSPI_DMA_RXT_WML_MASK; - writel(dma | - spi_imx->wml << MX51_ECSPI_DMA_RXT_WML_OFFSET, - spi_imx->base + MX51_ECSPI_DMA); } spi_imx->dma_finished = 1; -- 2.6.3 -- 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-sunxi] [PATCH 01/23] mtd: kill the ecclayout->oobavail field
On Mon, 2015-12-07 at 23:25 +0100, Boris Brezillon wrote: > ecclayout->oobavail is just redundant with the mtd->oobavail field. > Moreover, it prevents static const definition of ecc layouts since > the > NAND framework is calculating this value based on the ecclayout- > >oobfree > field. > > Signed-off-by: Boris Brezillon > --- > drivers/mtd/devices/docg3.c | 5 ++- > drivers/mtd/mtdswap.c | 16 - > drivers/mtd/nand/brcmnand/brcmnand.c | 3 -- > drivers/mtd/nand/docg4.c | 1 - > drivers/mtd/nand/hisi504_nand.c | 1 - > drivers/mtd/nand/nand_base.c | 12 +++ > drivers/mtd/onenand/onenand_base.c| 16 - > drivers/mtd/tests/oobtest.c | 49 +-- > > drivers/staging/mt29f_spinand/mt29f_spinand.c | 1 - > fs/jffs2/wbuf.c | 6 ++-- > include/linux/mtd/mtd.h | 1 - > 11 files changed, 48 insertions(+), 63 deletions(-) > [..] > > diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c > b/drivers/mtd/nand/brcmnand/brcmnand.c > index 35d78f7..a906ec2 100644 > --- a/drivers/mtd/nand/brcmnand/brcmnand.c > +++ b/drivers/mtd/nand/brcmnand/brcmnand.c > @@ -845,9 +845,6 @@ static struct nand_ecclayout *brcmnand_create_layout(int > ecc_level, > break; > } > out: > - /* Sum available OOB */ > - for (i = 0; i < MTD_MAX_OOBFREE_ENTRIES_LARGE; i++) > - layout->oobavail += layout->oobfree[i].length; > return layout; > } You can get rid of the 'out' label and replace the single goto in this function with 'return layout'. [...] > > diff --git a/drivers/mtd/nand/nand_base.c > b/drivers/mtd/nand/nand_base.c > index 0748a13..1107f5c1 100644 > --- a/drivers/mtd/nand/nand_base.c > +++ b/drivers/mtd/nand/nand_base.c > @@ -2037,7 +2037,7 @@ static int nand_do_read_oob(struct mtd_info > *mtd, loff_t from, > stats = mtd->ecc_stats; > > if (ops->mode == MTD_OPS_AUTO_OOB) > - len = chip->ecc.layout->oobavail; > + len = mtd->oobavail; > else > len = mtd->oobsize; > > @@ -2728,7 +2728,7 @@ static int nand_do_write_oob(struct mtd_info > *mtd, loff_t to, > __func__, (unsigned int)to, (int)ops- > >ooblen); > > if (ops->mode == MTD_OPS_AUTO_OOB) > - len = chip->ecc.layout->oobavail; > + len = mtd->oobavail; > else > len = mtd->oobsize; > [...] > diff --git a/drivers/mtd/onenand/onenand_base.c > b/drivers/mtd/onenand/onenand_base.c > index 43b3392..d70bbfd 100644 > --- a/drivers/mtd/onenand/onenand_base.c > +++ b/drivers/mtd/onenand/onenand_base.c > @@ -1125,7 +1125,7 @@ static int onenand_mlc_read_ops_nolock(struct > mtd_info *mtd, loff_t from, > (int)len); > > if (ops->mode == MTD_OPS_AUTO_OOB) > - oobsize = this->ecclayout->oobavail; > + oobsize = mtd->oobavail; > else > oobsize = mtd->oobsize; > > @@ -1230,7 +1230,7 @@ static int onenand_read_ops_nolock(struct > mtd_info *mtd, loff_t from, > (int)len); > > if (ops->mode == MTD_OPS_AUTO_OOB) > - oobsize = this->ecclayout->oobavail; > + oobsize = mtd->oobavail; > else > oobsize = mtd->oobsize; > > @@ -1365,7 +1365,7 @@ static int onenand_read_oob_nolock(struct > mtd_info *mtd, loff_t from, > ops->oobretlen = 0; > > if (mode == MTD_OPS_AUTO_OOB) > - oobsize = this->ecclayout->oobavail; > + oobsize = mtd->oobavail; > else > oobsize = mtd->oobsize; > > @@ -1887,7 +1887,7 @@ static int onenand_write_ops_nolock(struct > mtd_info *mtd, loff_t to, > return 0; > > if (ops->mode == MTD_OPS_AUTO_OOB) > - oobsize = this->ecclayout->oobavail; > + oobsize = mtd->oobavail; > else > oobsize = mtd->oobsize; > > @@ -2063,7 +2063,7 @@ static int onenand_write_oob_nolock(struct > mtd_info *mtd, loff_t to, > ops->oobretlen = 0; > > if (mode == MTD_OPS_AUTO_OOB) > - oobsize = this->ecclayout->oobavail; > + oobsize = mtd->oobavail; > else > oobsize = mtd->oobsize; This identical construction seems to occur multiple times in multiple files. Would it make sense to create a macro for it? Päikest, Priit Laes :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: sunxi: Extend the simple gates and handle the Allwinner H3
On Mon, 7 Dec 2015 08:31:02 -0600
Rob Herring wrote:
> On Sun, Dec 06, 2015 at 10:04:12AM +0100, Jean-Francois Moine wrote:
> > The H3 has a clock gate definition similar to the other Allwinner SoCs,
> > but with a different parent clock for each single gate.
> >
> > Adding the names of the parent clocks in both the source and output clocks
> > permits the use of the simple-gates driver to define the bus gates
> > of all known Allwinner SoCs.
> >
> > Signed-off-by: Jean-Francois Moine
> > ---
> > This patch replaces a part of Jens Kuske's patch
> > [PATCH v5 1/4] clk: sunxi: Add H3 clocks support
> > ---
> > Documentation/devicetree/bindings/clock/sunxi.txt | 25
> > +++
> > drivers/clk/sunxi/clk-simple-gates.c | 14 -
> > 2 files changed, 38 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
> > b/Documentation/devicetree/bindings/clock/sunxi.txt
> > index 8a47b77..5736e6d 100644
> > --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> > +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> > @@ -70,6 +70,7 @@ Required properties:
> > "allwinner,sun8i-a23-usb-clk" - for usb gates + resets on A23
> > "allwinner,sun9i-a80-usb-mod-clk" - for usb gates + resets on A80
> > "allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
> > + "allwinner,sunxi-gates-clk" - simple gates
> >
> > Required properties for all clocks:
> > - reg : shall be the control register address for the clock.
> > @@ -93,6 +94,12 @@ The "allwinner,sun9i-a80-mmc-config-clk" clock also
> > requires:
> > - #reset-cells : shall be set to 1
> > - resets : shall be the reset control phandle for the mmc block.
> >
> > +The "allwinner,sunxi-gates-clk" clock also requires:
> > +- clock-names : corresponding names of the parent clocks
> > +when the output clocks have different parents.
> > +These names must be 4 characters long and must appear as a prefix in
> > +the names of the output clocks. See example.
> > +
>
> I don't think you should be encoding relationships of clocks using the
> name strings. We describe relationships in DT via parent/child or
> phandles.
As you know, in the H3, each of the 49 output clock has one of the 4
main clocks as its source.
There are 3 options for defining the source of each clock:
1- all definitions are in the DT,
2- some definitions are in the DT, some other ones are hard-coded,
3- all definitions are hard-coded.
The 2nd option is the one proposed by Jens
https://lkml.org/lkml/2015/12/4/689
In the code, the clock index gives the source clock.
This means that this code is H3 specific and that it cannot be reused
for an other SoC.
So, instead of putting some information in the DT, the 3rd option could
be done without too much overhead with a DT:
bus_gates: clk@01c20060 {
#clock-cells = <1>;
compatible = "allwinner,sun8i-h3-bus-gates-clk";
reg = <0x01c20060 0x14>;
clocks = <>, <>, <>, <>;
clock-names = "ahb1", "ahb2", "apb1", "apb2";
/* no clock-indices, nor clock-output-names,
* these ones are hard-coded */
};
But, this option, as the previous one, implies new code for each new
SoC.
I better like the 1st option (reusable/generic code).
This one may be done in many ways:
1.1- define a source phandle of each output clock.
There were many proposals for such definitions, the simplest being
mine:
https://lkml.org/lkml/2015/10/22/109
but this asked for a long list in 'clocks', and Maxime did not like
that.
1.2- use a container per source clock
https://lkml.org/lkml/2015/10/23/?663
1.3- use a part of the name of the output clock as the source reference.
Current proposal, which seemed to suit Maxime
https://lkml.org/lkml/2015/10/26/647
1.4- have you any other idea?
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
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: Skein: Moved macros from skein_block.c to header file.
The original code defined macros in the source code, making it
harder to read. Moved them to the header file, as per the TODO file.
Upadated the TODO file.
Signed-off-by: Sanidhya Solanki
---
drivers/staging/skein/TODO | 1 -
drivers/staging/skein/skein_block.c | 6 --
drivers/staging/skein/skein_block.h | 7 +++
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/skein/TODO b/drivers/staging/skein/TODO
index cd3508d..e3de0c7 100644
--- a/drivers/staging/skein/TODO
+++ b/drivers/staging/skein/TODO
@@ -1,6 +1,5 @@
skein/threefish TODO
- - move macros into appropriate header files
- add / pass test vectors
- module support
diff --git a/drivers/staging/skein/skein_block.c
b/drivers/staging/skein/skein_block.c
index 45b4732..2120392 100644
--- a/drivers/staging/skein/skein_block.c
+++ b/drivers/staging/skein/skein_block.c
@@ -26,12 +26,6 @@
#define SKEIN_LOOP 001 /* default: unroll 256 and 512, but not 1024 */
#endif
-#define BLK_BITS(WCNT * 64) /* some useful definitions for code here */
-#define KW_TWK_BASE (0)
-#define KW_KEY_BASE (3)
-#define ks (kw + KW_KEY_BASE)
-#define ts (kw + KW_TWK_BASE)
-
#ifdef SKEIN_DEBUG
#define debug_save_tweak(ctx) \
{ \
diff --git a/drivers/staging/skein/skein_block.h
b/drivers/staging/skein/skein_block.h
index 9d40f4a..0fd4bfe 100644
--- a/drivers/staging/skein/skein_block.h
+++ b/drivers/staging/skein/skein_block.h
@@ -7,6 +7,13 @@
** This algorithm and source code is released to the public domain.
**
/
+
+#define BLK_BITS(WCNT * 64) /* some useful definitions for code here */
+#define KW_TWK_BASE (0)
+#define KW_KEY_BASE (3)
+#define ks (kw + KW_KEY_BASE)
+#define ts (kw + KW_TWK_BASE)
+
#ifndef _SKEIN_BLOCK_H_
#define _SKEIN_BLOCK_H_
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next] net: hns: optimize XGE capability by reducing cpu usage
On 2015/12/8 14:22, Yankejian (Hackim Yim) wrote: On 2015/12/7 16:58, Du, Fan wrote: > > >On 2015/12/5 15:32, yankejian wrote: >>here is the patch raising the performance of XGE by: >>1)changes the way page management method for enet momery, and >>2)reduces the count of rmb, and >>3)adds Memory prefetching > >Any numbers on how much it boost performance? > it is almost the same as 82599. I mean how much it improves performance *BEFORE* and *AFTER* this patch for Huawei XGE chip, because the commit log states it "raising the performance", but did give numbers of the testing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/8] cpufreq: add generic cpufreq driver support for Exynos542x/5800 platforms
On 08-12-15, 11:47, Viresh Kumar wrote: > On 07-12-15, 19:18, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > > > This patch series adds generic cpufreq-dt driver support for > > Exynos542x/5800 (using the new CPU clock type which allows it). > > > > It has been tested on Exynos5422 based ODROID-XU3 Lite board. > > Excellent work Bartlomiej. Thanks a lot for adapting cpufreq-dt for > this. Really appreciate it :) You fix the oppXX@ problem and add my Acked-by: Viresh Kumar for the entire series. Good work. -- 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/
Re: [PATCH v4 3/8] ARM: dts: Exynos5420: add CPU OPP properties
On 07-12-15, 19:18, Bartlomiej Zolnierkiewicz wrote:
> + cpu1_opp_table: opp_table1 {
> + compatible = "operating-points-v2";
> + opp-shared;
> + opp00@13 {
This should be just opp@13, you don't need 00/01/02... anymore
now. Same for the other patch as well..
Fix that in other patches in this series and you also need to fix it
for arch/arm/boot/dts/exynos4212.dtsi based on what I see in
linux-next.
--
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/
Re: [PATCH net-next] net: hns: optimize XGE capability by reducing cpu usage
On 2015/12/7 16:58, Du, Fan wrote:
>
>
> On 2015/12/5 15:32, yankejian wrote:
>> here is the patch raising the performance of XGE by:
>> 1)changes the way page management method for enet momery, and
>> 2)reduces the count of rmb, and
>> 3)adds Memory prefetching
>
> Any numbers on how much it boost performance?
>
it is almost the same as 82599.
>> Signed-off-by: yankejian
>> ---
>> drivers/net/ethernet/hisilicon/hns/hnae.h | 5 +-
>> drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c | 1 -
>> drivers/net/ethernet/hisilicon/hns/hns_enet.c | 79
>> +++
>> 3 files changed, 55 insertions(+), 30 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/hisilicon/hns/hnae.h
>> b/drivers/net/ethernet/hisilicon/hns/hnae.h
>> index d1f3316..6ca94dc 100644
>> --- a/drivers/net/ethernet/hisilicon/hns/hnae.h
>> +++ b/drivers/net/ethernet/hisilicon/hns/hnae.h
>> @@ -341,7 +341,8 @@ struct hnae_queue {
>> void __iomem *io_base;
>> phys_addr_t phy_base;
>> struct hnae_ae_dev *dev;/* the device who use this queue */
>> -struct hnae_ring rx_ring, tx_ring;
>> +struct hnae_ring rx_ring cacheline_internodealigned_in_smp;
>> +struct hnae_ring tx_ring cacheline_internodealigned_in_smp;
>> struct hnae_handle *handle;
>> };
>>
>> @@ -597,11 +598,9 @@ static inline void hnae_replace_buffer(struct hnae_ring
>> *ring, int i,
>> struct hnae_desc_cb *res_cb)
>> {
>> struct hnae_buf_ops *bops = ring->q->handle->bops;
>> -struct hnae_desc_cb tmp_cb = ring->desc_cb[i];
>>
>> bops->unmap_buffer(ring, >desc_cb[i]);
>> ring->desc_cb[i] = *res_cb;
>> -*res_cb = tmp_cb;
>> ring->desc[i].addr = (__le64)ring->desc_cb[i].dma;
>> ring->desc[i].rx.ipoff_bnum_pid_flag = 0;
>> }
>> diff --git a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
>> b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
>> index 77c6edb..522b264 100644
>> --- a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
>> +++ b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
>> @@ -341,7 +341,6 @@ void hns_ae_toggle_ring_irq(struct hnae_ring *ring, u32
>> mask)
>> else
>> flag = RCB_INT_FLAG_RX;
>>
>> -hns_rcb_int_clr_hw(ring->q, flag);
>> hns_rcb_int_ctrl_hw(ring->q, flag, mask);
>> }
>>
>> diff --git a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
>> b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
>> index cad2663..e2be510 100644
>> --- a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
>> +++ b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
>> @@ -33,6 +33,7 @@
>>
>> #define RCB_IRQ_NOT_INITED 0
>> #define RCB_IRQ_INITED 1
>> +#define HNS_BUFFER_SIZE_2048 2048
>>
>> #define BD_MAX_SEND_SIZE 8191
>> #define SKB_TMP_LEN(SKB) \
>> @@ -491,13 +492,51 @@ static unsigned int hns_nic_get_headlen(unsigned char
>> *data, u32 flag,
>> return max_size;
>> }
>>
>> -static void
>> -hns_nic_reuse_page(struct hnae_desc_cb *desc_cb, int tsize, int last_offset)
>> +static void hns_nic_reuse_page(struct sk_buff *skb, int i,
>> + struct hnae_ring *ring, int pull_len,
>> + struct hnae_desc_cb *desc_cb)
>> {
>> +struct hnae_desc *desc;
>> +int truesize, size;
>> +int last_offset = 0;
>> +
>> +desc = >desc[ring->next_to_clean];
>> +size = le16_to_cpu(desc->rx.size);
>> +
>> +#if (PAGE_SIZE < 8192)
>> +if (hnae_buf_size(ring) == HNS_BUFFER_SIZE_2048) {
>> +truesize = hnae_buf_size(ring);
>> +} else {
>> +truesize = ALIGN(size, L1_CACHE_BYTES);
>> +last_offset = hnae_page_size(ring) - hnae_buf_size(ring);
>> +}
>> +
>> +#else
>> +truesize = ALIGN(size, L1_CACHE_BYTES);
>> +last_offset = hnae_page_size(ring) - hnae_buf_size(ring);
>> +#endif
>> +
>> +skb_add_rx_frag(skb, i, desc_cb->priv, desc_cb->page_offset + pull_len,
>> +size - pull_len, truesize - pull_len);
>> +
>>/* avoid re-using remote pages,flag default unreuse */
>> if (likely(page_to_nid(desc_cb->priv) == numa_node_id())) {
>> +#if (PAGE_SIZE < 8192)
>> +if (hnae_buf_size(ring) == HNS_BUFFER_SIZE_2048) {
>> +/* if we are only owner of page we can reuse it */
>> +if (likely(page_count(desc_cb->priv) == 1)) {
>> +/* flip page offset to other buffer */
>> +desc_cb->page_offset ^= truesize;
>> +
>> +desc_cb->reuse_flag = 1;
>> +/* bump ref count on page before it is given*/
>> +get_page(desc_cb->priv);
>> +}
>> +return;
>> +}
>> +#endif
>> /* move offset up to the next cache line */
>> -desc_cb->page_offset += tsize;
>> +desc_cb->page_offset += truesize;
>>
>> if (desc_cb->page_offset <= last_offset) {
>> desc_cb->reuse_flag = 1;
>> @@ -529,11 +568,10 @@ static int hns_nic_poll_rx_skb(struct
>>
RE: [PATCH linux-next 0/5] mtd: spi-nor: add driver for Atmel QSPI controller
> -Original Message-
> From: Brian Norris [mailto:computersforpe...@gmail.com]
> Sent: Tuesday, December 08, 2015 3:35 AM
> To: Cyrille Pitchen
> Cc: linux-...@lists.infradead.org; nicolas.fe...@atmel.com; ma...@denx.de;
> vigne...@ti.com; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;
> robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com;
> ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; Bean Huo 霍斌斌
> (beanhuo)
> Subject: Re: [PATCH linux-next 0/5] mtd: spi-nor: add driver for Atmel QSPI
> controller
>
> + Bean Huo
>
> Hi Cyrille,
>
> On Mon, Dec 07, 2015 at 03:09:09PM +0100, Cyrille Pitchen wrote:
> > Hi all,
> >
> > this series of patches adds support to the Atmel QSPI controller
> > available on sama5d2 SoCs. It was tested on a sama5d2 xplained ultra
> > board with a Micron n25q128a13 QSPI memory and a at25df321a SPI
> memory.
> >
> > In order to use the Micron memory in its Quad SPI mode, the spi-nor
> > framework needed to be patched to fix the support of Quad/Dual SPI
> > protocols with some memory manufacturers such as Spansion, Micron and
> > Macronix. There are many comments in the source code to explain the
> > implementation choices based on the datasheets from memory
> manufacturers.
> >
> >
> > This series was based and tested on linux-next-20151207
> >
> > 1 - Atmel QSPI + Micron n25q128a13 (atmel-quadspi.c driver)
> >
> > SPI 1-1-1: This mode was tested replacing SPI_NOR_QUAD by
> SPI_NOR_FAST as
> >argument to spi_nor_scan() called from atmel_qspi_probe().
> >
> > SPI 1-1-4: Bootloaders (at91bootstrap/uboot) don't enable the Quad SPI
> >mode of the Micron memory. When probed from Linux, the
> memory
> >uses its Extended SPI mode and replies to the regular Read ID
> >(0x9f) command.
> >
> > SPI 4-4-4: The romcode enabled the Quad SPI mode the of Micron memory
> >before loading the at91bootstrap. When probed from Linux,
> the
> >memory uses its Quad SPI mode and no longer replies to the
> >regular Read ID (0x9f) command but instead to the Read ID
> >Multiple I/O (0xaf) command. The memory expects ALL
> commands
> >to use the SPI 4-4-4 protocol.
>
> I'll admit I'm a little fuzzy on the differences between dual and quad modes
> on
> various flash manufacturers. Can you help clear it up for me?
For Micron SPI NOR spi quad mode, means that Qaud I/O prototocol, it follows I/O
Bus width is command-address-Data 4-4-4, at this time, DQ0,DQ1,DQ2,DQ3
are all used to transfer address/command/data. For this maybe not the same
between
different flash manufactures. For example, for Spansion Qspi NOR, its all
instructions are
transferred from host to memory as a single bit serial sequence on the DQ0
signal, even under
Quad mode. Dual mode the same as Qaud mode scenario.
for SPI NOR 1-1-4, means command and address are transferred on the DQ0,
but for data, being transferred on DQ0,DQ1,DQ2,DQ3.For this, it is the same
between different flash manufacturers. Of course, at this moment, SPI NOR
should work under extended I/O mode.
> I think some of the comments on patch 2 help too, but I'll just comment here
> for now.
> It looks like the current driver has problems regarding the non 1-x-y modes
> (e.g., 4-4-4), right? But I see that spi-nor.c never tries to send a 4_4_4
> command; it only sets read_opcode to SPINOR_OP_READ_1_1_{1,2,4}. So is
> this an oversight in patches like Bean's patch?
For SPINOR_OP_READ_1_1_{1,2,4} commands, Spi NOR actually works under
Extended I/O mode, not Quad mode. They just push Spi NOR output data by Quad
mode,
Command and address still following extended I/O mode.
For 4-4-4 I/O protocol, SPI NOR should change to Quad mode(just as my patch),
of course, SPI controller should support this. for Micron Qspi NOR, under quad
mode,
all commands/address/data are transferred on DQ0,DQ1,DQ2,DQ3 signals. No matter
what
kind of command.
> commit 548cd3ab54da ("mtd: spi-nor: Add quad I/O support for Micron
> SPI NOR")
>
> Why would we even need to enable quad modes like that, if we're not going
> to send the 4-4-4 opcodes?
I think, in order to high speed SPI NOR, after enable quad mode,
SPINOR_OP_READ_1_1_{1,2,4} commands don't need any more, normal read command
(0x03)
Can implement as them.
> My next question (if my understanding is roughly correct) is, do we need the
> 4-4-4 modes, and what risks come with them? I understand we can shorten
> the command and address phases, but does that alone yield much
> performance benefit? And I think the risk is that a give
[PATCH v5 2/2] block: create ioctl to discard-or-zeroout a range of blocks
Create a new ioctl to expose the block layer's newfound ability to
issue either a zeroing discard, a WRITE SAME with a zero page, or a
regular write with the zero page. This BLKZEROOUT2 ioctl takes
{start, length, flags} as parameters. So far, the only flag available
is to enable the zeroing discard part -- without it, the call invokes
the old BLKZEROOUT behavior. start and length have the same meaning
as in BLKZEROOUT.
This new ioctl also invalidates the page cache correctly on account
of the previous patch in the series.
v3: Add extra padding for future expansion, and check the padding is zero.
v4: Check the start/len arguments for overflows prior to feeding the page
cache bogus numbers (that it'll ignore anyway).
v5: Refactor the 4.4 refactoring of the ioctl code into separate functions.
Separate patches for invalidation and new ioctl.
Signed-off-by: Darrick J. Wong
---
block/ioctl.c | 57 ---
include/uapi/linux/fs.h |9 +++
2 files changed, 53 insertions(+), 13 deletions(-)
diff --git a/block/ioctl.c b/block/ioctl.c
index d06646d..f6d7b5d 100644
--- a/block/ioctl.c
+++ b/block/ioctl.c
@@ -221,24 +221,20 @@ static int blk_ioctl_discard(struct block_device *bdev,
fmode_t mode,
return blkdev_issue_discard(bdev, start, len, GFP_KERNEL, flags);
}
-static int blk_ioctl_zeroout(struct block_device *bdev, fmode_t mode,
- unsigned long arg)
+static int __blk_ioctl_zeroout(struct block_device *bdev,
+ unsigned long long start,
+ unsigned long long len,
+ unsigned int flags)
{
- uint64_t range[2];
struct address_space *mapping;
- uint64_t start, end, len;
+ unsigned long long end;
+ bool discard = false;
int ret;
- if (!(mode & FMODE_WRITE))
- return -EBADF;
-
- if (copy_from_user(range, (void __user *)arg, sizeof(range)))
- return -EFAULT;
-
- start = range[0];
- len = range[1];
end = start + len - 1;
+ if (flags & ~BLKZEROOUT2_DISCARD_OK)
+ return -EINVAL;
if (start & 511)
return -EINVAL;
if (len & 511)
@@ -252,8 +248,10 @@ static int blk_ioctl_zeroout(struct block_device *bdev,
fmode_t mode,
mapping = bdev->bd_inode->i_mapping;
truncate_inode_pages_range(mapping, start, end);
+ if (flags & BLKZEROOUT2_DISCARD_OK)
+ discard = true;
ret = blkdev_issue_zeroout(bdev, start >> 9, len >> 9, GFP_KERNEL,
- false);
+ discard);
if (ret)
return ret;
@@ -266,6 +264,37 @@ static int blk_ioctl_zeroout(struct block_device *bdev,
fmode_t mode,
end >> PAGE_CACHE_SHIFT);
}
+static int blk_ioctl_zeroout(struct block_device *bdev, fmode_t mode,
+ unsigned long arg)
+{
+ uint64_t range[2];
+
+ if (!(mode & FMODE_WRITE))
+ return -EBADF;
+
+ if (copy_from_user(range, (void __user *)arg, sizeof(range)))
+ return -EFAULT;
+
+ return __blk_ioctl_zeroout(bdev, range[0], range[1], 0);
+}
+
+static int blk_ioctl_zeroout2(struct block_device *bdev, fmode_t mode,
+ unsigned long arg)
+{
+ struct blkzeroout2 p;
+
+ if (!(mode & FMODE_WRITE))
+ return -EBADF;
+
+ if (copy_from_user(, (void __user *)arg, sizeof(p)))
+ return -EFAULT;
+
+ if (p.padding || p.padding2)
+ return -EINVAL;
+
+ return __blk_ioctl_zeroout(bdev, p.start, p.length, p.flags);
+}
+
static int put_ushort(unsigned long arg, unsigned short val)
{
return put_user(val, (unsigned short __user *)arg);
@@ -530,6 +559,8 @@ int blkdev_ioctl(struct block_device *bdev, fmode_t mode,
unsigned cmd,
BLKDEV_DISCARD_SECURE);
case BLKZEROOUT:
return blk_ioctl_zeroout(bdev, mode, arg);
+ case BLKZEROOUT2:
+ return blk_ioctl_zeroout2(bdev, mode, arg);
case HDIO_GETGEO:
return blkdev_getgeo(bdev, argp);
case BLKRAGET:
diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
index f15d980..6decbac 100644
--- a/include/uapi/linux/fs.h
+++ b/include/uapi/linux/fs.h
@@ -152,6 +152,15 @@ struct inodes_stat_t {
#define BLKSECDISCARD _IO(0x12,125)
#define BLKROTATIONAL _IO(0x12,126)
#define BLKZEROOUT _IO(0x12,127)
+struct blkzeroout2 {
+ __u64 start;
+ __u64 length;
+ __u32 flags;
+ __u32 padding;
+ __u64 padding2;
+};
+#define BLKZEROOUT2_DISCARD_OK 1
+#define BLKZEROOUT2 _IOR(0x12, 127, struct blkzeroout2)
#define BMAP_IOCTL 1 /* obsolete - kept for compatibility */
#define FIBMAP_IO(0x00,1) /* bmap access */
--
To unsubscribe from this
[PATCH v5 1/2] block: invalidate the page cache when issuing BLKZEROOUT.
Invalidate the page cache (as a regular O_DIRECT write would do) to avoid
returning stale cache contents at a later time.
v5: Refactor the 4.4 refactoring of the ioctl code into separate functions.
Split the page invalidation and the new ioctl into separate patches.
Signed-off-by: Darrick J. Wong
---
block/ioctl.c | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/block/ioctl.c b/block/ioctl.c
index 0918aed..d06646d 100644
--- a/block/ioctl.c
+++ b/block/ioctl.c
@@ -225,7 +225,9 @@ static int blk_ioctl_zeroout(struct block_device *bdev,
fmode_t mode,
unsigned long arg)
{
uint64_t range[2];
- uint64_t start, len;
+ struct address_space *mapping;
+ uint64_t start, end, len;
+ int ret;
if (!(mode & FMODE_WRITE))
return -EBADF;
@@ -235,18 +237,33 @@ static int blk_ioctl_zeroout(struct block_device *bdev,
fmode_t mode,
start = range[0];
len = range[1];
+ end = start + len - 1;
if (start & 511)
return -EINVAL;
if (len & 511)
return -EINVAL;
- start >>= 9;
- len >>= 9;
-
- if (start + len > (i_size_read(bdev->bd_inode) >> 9))
+ if (end >= (uint64_t)i_size_read(bdev->bd_inode))
+ return -EINVAL;
+ if (end < start)
return -EINVAL;
- return blkdev_issue_zeroout(bdev, start, len, GFP_KERNEL, false);
+ /* Invalidate the page cache, including dirty pages */
+ mapping = bdev->bd_inode->i_mapping;
+ truncate_inode_pages_range(mapping, start, end);
+
+ ret = blkdev_issue_zeroout(bdev, start >> 9, len >> 9, GFP_KERNEL,
+ false);
+ if (ret)
+ return ret;
+
+ /*
+* Invalidate again; if someone wandered in and dirtied a page,
+* the caller will be given -EBUSY.
+*/
+ return invalidate_inode_pages2_range(mapping,
+start >> PAGE_CACHE_SHIFT,
+end >> PAGE_CACHE_SHIFT);
}
static int put_ushort(unsigned long arg, unsigned short val)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/8] cpufreq: add generic cpufreq driver support for Exynos542x/5800 platforms
On 07-12-15, 19:18, Bartlomiej Zolnierkiewicz wrote: > Hi, > > This patch series adds generic cpufreq-dt driver support for > Exynos542x/5800 (using the new CPU clock type which allows it). > > It has been tested on Exynos5422 based ODROID-XU3 Lite board. Excellent work Bartlomiej. Thanks a lot for adapting cpufreq-dt for this. Really appreciate it :) -- 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/
Re: [v2 0/2] ata/libata-eh.c: introduce ATA_FLAG_NO_LOG_PAGE
On Mon, Dec 07, 2015 at 10:26:30AM -0500, Tejun Heo wrote: > On Fri, Dec 04, 2015 at 06:12:24PM +0100, Andreas Werner wrote: > > This patchset add a new ata port flag ATA_FLAG_NO_LOG_PAGE to be able > > to blacklist ports/controller which e.g. locks up on a log page read. > > > > This flag is added to the sata_fsl driver which is the first affected > > one. > > > > The lockup was detected on Freescale P1013/P1022, T4240 using a ATP > > mSATA. > > The device failed during initialisation if the SATA device includes the > > devslp feature. > > > > With this patchset, we blacklist the fsl sata controller and return > > a error on any attempt to read a log page. This allows us to access > > the mSATA. > > Applied 1-2 to libata/for-4.4-fixes. > > Thanks. > > -- > tejun Thanks Tejun for the discussion and that the patch was applied :-) Regards Andy -- 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/
netlink: Add missing goto statement to netlink_insert
On Mon, Dec 07, 2015 at 07:58:25AM +0100, Stefan Priebe - Profihost AG wrote:
>
> Thanks, good. Can you help me to get this fix upstream into the stable
> lines?
Sure. Greg, please apply this patch to fix up the backport for 4.1.
---8<---
The backport of 1f770c0a09da855a2b51af6d19de97fb955eca85 ("netlink:
Fix autobind race condition that leads to zero port ID") missed a
goto statement, which causes netlink to break subtly.
This was discovered by Stefan Priebe .
Fixes: 4e2776241766 ("netlink: Fix autobind race condition that...")
Reported-by: Stefan Priebe
Reported-by: Philipp Hahn
Signed-off-by: Herbert Xu
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index d139c43..0d6038c 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1118,6 +1118,7 @@ static int netlink_insert(struct sock *sk, u32 portid)
if (err == -EEXIST)
err = -EADDRINUSE;
sock_put(sk);
+ goto err;
}
/* We need to ensure that the socket is hashed and visible. */
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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] blk-mg-tag: Make tag's codeflow more reasonably during initializing
Ping.
Any comment is appreciate.
Thanks
Minfei
On 11/27/15 at 04:37pm, Minfei Huang wrote:
> From: Minfei Huang
>
> It might be more reasonable to cleanup all of the allocations in same
> function, if there is a fatal. Thus we can make function more
> independency to export it.
>
> For this patch, variant tag will be allocated in blk_mq_init_tags, and
> it will be freed in same function, if there is an error during
> initializing the tag.
>
> What the blk_mq_init_bitmap_tags does is to allocate bitmap.
>
> Signed-off-by: Minfei Huang
> ---
> block/blk-mq-tag.c | 30 ++
> 1 file changed, 18 insertions(+), 12 deletions(-)
>
> diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
> index a07ca34..7a1d9a8 100644
> --- a/block/blk-mq-tag.c
> +++ b/block/blk-mq-tag.c
> @@ -596,23 +596,24 @@ static void bt_free(struct blk_mq_bitmap_tags *bt)
> kfree(bt->bs);
> }
>
> -static struct blk_mq_tags *blk_mq_init_bitmap_tags(struct blk_mq_tags *tags,
> -int node, int alloc_policy)
> +static int blk_mq_init_bitmap_tags(struct blk_mq_tags *tags,
> + int node, int alloc_policy)
> {
> + int ret = 0;
> unsigned int depth = tags->nr_tags - tags->nr_reserved_tags;
>
> tags->alloc_policy = alloc_policy;
>
> - if (bt_alloc(>bitmap_tags, depth, node, false))
> - goto enomem;
> - if (bt_alloc(>breserved_tags, tags->nr_reserved_tags, node, true))
> - goto enomem;
> + ret = bt_alloc(>bitmap_tags, depth, node, false);
> + if (ret)
> + goto out;
>
> - return tags;
> -enomem:
> - bt_free(>bitmap_tags);
> - kfree(tags);
> - return NULL;
> + ret = bt_alloc(>breserved_tags,
> + tags->nr_reserved_tags, node, true);
> + if (ret)
> + bt_free(>bitmap_tags);
> +out:
> + return ret;
> }
>
> struct blk_mq_tags *blk_mq_init_tags(unsigned int total_tags,
> @@ -638,7 +639,12 @@ struct blk_mq_tags *blk_mq_init_tags(unsigned int
> total_tags,
> tags->nr_tags = total_tags;
> tags->nr_reserved_tags = reserved_tags;
>
> - return blk_mq_init_bitmap_tags(tags, node, alloc_policy);
> + if (blk_mq_init_bitmap_tags(tags, node, alloc_policy)) {
> + kfree(tags);
> + return NULL;
> + }
> +
> + return tags;
> }
>
> void blk_mq_free_tags(struct blk_mq_tags *tags)
> --
> 1.8.3.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 3/7] arm64: Kprobes with single stepping support
On 08/12/15 09:37, Will Deacon wrote:
Hi David,
Thanks for the patch. Took me a while to get through it and I suspect
I missed things, but comments inline all the same.
Sorry for the big delay in responding. You did have a fair few
questions though. I'm still chasing down a couple answers.
On Tue, Aug 11, 2015 at 01:52:40AM +0100, David Long wrote:
From: Sandeepa Prabhu
Add support for basic kernel probes(kprobes) and jump probes
(jprobes) for ARM64.
Kprobes utilizes software breakpoint and single step debug
exceptions supported on ARM v8.
A software breakpoint is placed at the probe address to trap the
kernel execution into the kprobe handler.
ARM v8 supports enabling single stepping before the break exception
return (ERET), with next PC in exception return address (ELR_EL1). The
kprobe handler prepares an executable memory slot for out-of-line
execution with a copy of the original instruction being probed, and
enables single stepping. The PC is set to the out-of-line slot address
before the ERET. With this scheme, the instruction is executed with the
exact same register context except for the PC (and DAIF) registers.
Debug mask (PSTATE.D) is enabled only when single stepping a recursive
kprobe, e.g.: during kprobes reenter so that probed instruction can be
single stepped within the kprobe handler -exception- context.
The recursion depth of kprobe is always 2, i.e. upon probe re-entry,
any further re-entry is prevented by not calling handlers and the case
counted as a missed kprobe).
Single stepping from the x-o-l slot has a drawback for PC-relative accesses
like branching and symbolic literals access as the offset from the new PC
(slot address) may not be ensured to fit in the immediate value of
the opcode. Such instructions need simulation, so reject
probing them.
Instructions generating exceptions or cpu mode change are rejected
for probing.
Instructions using Exclusive Monitor are rejected too.
System instructions are mostly enabled for stepping, except MSR/MRS
accesses to "DAIF" flags in PSTATE, which are not safe for
probing.
I can imagine other MSR instructions that aren't safe for probing too
For example, disabling the MMU. Maybe we should just blanket-ban these
guys for now?
Yeah, done.
diff --git a/arch/arm64/include/asm/debug-monitors.h
b/arch/arm64/include/asm/debug-monitors.h
index 40ec68a..92d7cea 100644
--- a/arch/arm64/include/asm/debug-monitors.h
+++ b/arch/arm64/include/asm/debug-monitors.h
@@ -90,6 +90,11 @@
#define CACHE_FLUSH_IS_SAFE1
+/* kprobes BRK opcodes with ESR encoding */
+#define BRK64_ESR_MASK 0x
+#define BRK64_ESR_KPROBES 0x0004
+#define BRK64_OPCODE_KPROBES (AARCH64_BREAK_MON | (BRK64_ESR_KPROBES << 5))
These are probably due some slight renaming with the BRK clean-up we've
got queued for 4.3.
I've made a minor change that I think addresses this.
/* AArch32 */
#define DBG_ESR_EVT_BKPT 0x4
#define DBG_ESR_EVT_VECC 0x5
diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
new file mode 100644
index 000..af31c4d
--- /dev/null
+++ b/arch/arm64/include/asm/kprobes.h
@@ -0,0 +1,62 @@
+/*
+ * arch/arm64/include/asm/kprobes.h
+ *
+ * Copyright (C) 2013 Linaro Limited
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#ifndef _ARM_KPROBES_H
+#define _ARM_KPROBES_H
+
+#include
+#include
+#include
+
+#define __ARCH_WANT_KPROBES_INSN_SLOT
+#define MAX_INSN_SIZE 1
+#define MAX_STACK_SIZE 128
+
+#define flush_insn_slot(p) do { } while (0)
+#define kretprobe_blacklist_size 0
+
+#include
+
+struct prev_kprobe {
+ struct kprobe *kp;
+ unsigned int status;
+};
+
+/* Single step context for kprobe */
+struct kprobe_step_ctx {
+#define KPROBES_STEP_NONE 0x0
+#define KPROBES_STEP_PENDING 0x1
+ unsigned long ss_status;
Why not bool ss_pending?
Presumably this was to allow for other possible states, which turned out
to be uneeded. I've changed it to a bool.
+ unsigned long match_addr;
+};
+
+/* per-cpu kprobe control block */
+struct kprobe_ctlblk {
+ unsigned int kprobe_status;
+ unsigned long saved_irqflag;
+ struct prev_kprobe prev_kprobe;
+ struct kprobe_step_ctx ss_ctx;
+ struct pt_regs jprobe_saved_regs;
+ char jprobes_stack[MAX_STACK_SIZE];
+};
+
+void arch_remove_kprobe(struct kprobe *);
+int kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr);
+int kprobe_exceptions_notify(struct notifier_block *self,
+
Re: [PATCH v5 08/11] spi: imx: allow only WML aligned transfers to use DMA
On Tue, Dec 08, 2015 at 01:33:18AM +0100, Anton Bondarenko wrote:
>
>
> On 2015-12-07 10:42, Sascha Hauer wrote:
> >On Sat, Dec 05, 2015 at 05:57:06PM +0100, Anton Bondarenko wrote:
> >>RX DMA tail data handling doesn't work correctly in many cases with current
> >>implementation. It happens because SPI core was setup to generates both RX
> >>and RX TAIL events. And RX TAIL event does not work correctly.
> >>This can be easily verified by sending SPI transaction with size modulus
> >>WML(32 in our case) not equal 0.
> >>
> >>Also removing change introduced in f6ee9b582d2db652497b73c1f117591dfb6d3a90
> >>since this change only fix usecases with transfer size from 33 to 128 bytes
> >>and does not fix 129 bytes etc.
> >>
> >>This is output from transaction with len 138 bytes in loopback mode at
> >>10Mhz:
> >>TX: a3 97 a2 55 53 be f1 fc f9 79 6b 52 14 13 e9 e2
> >>TX0010: 2d 51 8e 1f 56 08 57 27 a7 05 d4 d0 52 82 77 75
> >>TX0020: 1b 99 4a ed 58 3d 6a 52 36 d5 24 4a 68 8e ad 95
> >>TX0030: 5f 3c 35 b5 c4 8c dd 6c 11 32 3d e2 b4 b4 59 cf
> >>TX0040: ce 23 3d 27 df a7 f9 96 fc 1e e0 66 2c 0e 7b 8c
> >>TX0050: ca 30 42 8f bc 9f 7b ce d1 b8 b1 87 ec 8a d6 bb
> >>TX0060: 2e 15 63 0e 3c dc a4 3a 7a 06 20 a7 93 1b 34 dd
> >>TX0070: 4c f5 ec 88 96 68 d6 68 a0 09 6f 8e 93 47 c9 41
> >>TX0080: db ac cf 97 89 f3 51 05 79 71
> >>
> >>RX: a3 97 a2 55 53 be f1 fc f9 79 6b 52 14 13 e9 e2
> >>RX0010: 2d 51 8e 1f 56 08 57 27 a7 05 d4 d0 52 82 77 75
> >>RX0020: 1b 99 4a ed 58 3d 6a 52 36 d5 24 4a 68 8e ad 95
> >>RX0030: 5f 3c 35 00 00 b5 00 00 00 c4 00 00 8c 00 00 dd
> >>RX0040: 6c 11 32 3d e2 b4 b4 59 cf ce 23 3d 27 df a7 f9
> >>RX0050: 96 fc 1e e0 66 2c 0e 7b 8c ca 30 42 8f 1f 1f bc
> >>RX0060: 9f 7b ce d1 b8 b1 87 ec 8a d6 bb 2e 15 63 0e ed
> >>RX0070: ed 3c 58 58 58 dc 3d 3d a4 6a 6a 3a 52 52 7a 36
> >>RX0080: 06 20 a7 93 1b 34 dd 4c f5 ec
> >>
> >>Zeros at offset 33 and 34 caused by reading empty RX FIFO which not possible
> >>if DMA RX read was triggered by RX event. This mean DMA was triggered
> >>by RX TAIL event.
> >>
> >>Signed-off-by: Anton Bondarenko
> >>---
> >> drivers/spi/spi-imx.c | 4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >>diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
> >>index fa24637..7a68c62 100644
> >>--- a/drivers/spi/spi-imx.c
> >>+++ b/drivers/spi/spi-imx.c
> >>@@ -204,8 +204,8 @@ static bool spi_imx_can_dma(struct spi_master *master,
> >>struct spi_device *spi,
> >> {
> >>struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
> >>
> >>- if (spi_imx->dma_is_inited &&
> >>- transfer->len > spi_imx->wml * sizeof(u32))
> >>+ if (spi_imx->dma_is_inited && transfer->len > spi_imx->wml &&
> >>+ (transfer->len % spi_imx->wml) == 0)
> >>return true;
> >
> >Must transfer->len really be bigger than spi_imx->wml? I would assume it
> >should be >= instead. And where is the * sizeof(u32) gone? If that's
> >unnecessary I heven't understood why.
> >
> >Sascha
> >
> >
>
> Agree on '>='. Will be in V6.
> As for missing sizeof(u32).
> According to SoC specification it's possible to operate with 8- or 16 bits
> word directly by setting proper value in word_width field in CFG register. I
> do not know the what exactly is fixed by f6ee9b582d, but I could suspect
> such scenario:
> Some SPI client (spi-nor?) trying to perform SPI transaction with len mod 32
> not equal zero. It could be any value between 33 and 127, excluding 64. But
> since DMA RX tail functionality does not work correctly RX contains some
> garbage.
I just tested it. Back then I had 60byte transfers with the SPI NOR
driver. What I got is:
spi_master spi0: I/O Error in DMA RX
spi_master spi0: failed to transfer one message from queue
I can't follow anymore what led me to the assumption that this issue is
related to byte/wordsize mixup. The SPI NOR driver uses 8bit transfers
so one word is one byte, something the driver handles correctly.
I just tested your series successfully with this usecase. I can redo the
test with v6 once you send it and provide my tested-by tag.
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: [PATCH 5/8 v4] thermal: rcar: enable to use thermal-zone on DT
Hi Morimoto-san,
Sorry for late information in v3.
There's a small mistake in example in DT binding documentation.
Anyway, let's wait for more comments from other developers before fixing it.
On 12/8/2015 12:28 PM, Kuninori Morimoto wrote:
From: Kuninori Morimoto
This patch enables to use thermal-zone on DT if it was call as
"renesas,rcar-gen2-thermal".
Previous style is still supported by "renesas,rcar-thermal".
Signed-off-by: Kuninori Morimoto
---
v3 -> v4
- no change
.../devicetree/bindings/thermal/rcar-thermal.txt | 37 +-
drivers/thermal/rcar_thermal.c | 44 +++---
2 files changed, 74 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
index 332e625..601a54d 100644
--- a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
@@ -1,8 +1,9 @@
* Renesas R-Car Thermal
Required properties:
-- compatible : "renesas,thermal-", "renesas,rcar-thermal"
- as fallback.
+- compatible : "renesas,thermal-",
+ "renesas,rcar-gen2-thermal" (with thermal-zone) or
+ "renesas,rcar-thermal" (without thermal-zone) as
fallback.
Examples with soctypes are:
- "renesas,thermal-r8a73a4" (R-Mobile APE6)
- "renesas,thermal-r8a7779" (R-Car H1)
@@ -36,3 +37,35 @@ thermal@e61f {
0xe61f0300 0x38>;
interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
};
+
+Example (with thermal-zone):
+
+thermal-zones {
+ cpu_thermal: cpu-thermal {
+ polling-delay-passive = <1000>;
+ polling-delay = <5000>;
+
+ thermal-sensors = <>;
+
+ trips {
+ cpu-crit {
+ temperature = <115>;
One zero is redundant here. It should be 115000.
Even though this is an example, the value 115 millicelcius degree is
too big for existing R-Car systems :)
+ hysteresis = <0>;
+ type= "critical";
+ };
+ };
+ cooling-maps {
+ };
+ };
+};
+
+thermal: thermal@e61f {
+ compatible ="renesas,thermal-r8a7790",
+ "renesas,rcar-gen2-thermal",
+ "renesas,rcar-thermal";
+ reg = <0 0xe61f 0 0x14>, <0 0xe61f0100 0 0x38>;
+ interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <_clks R8A7790_CLK_THERMAL>;
+ power-domains = <_clocks>;
+ #thermal-sensor-cells = <0>;
+};
diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
index 40c3ba5..d4d2661 100644
--- a/drivers/thermal/rcar_thermal.c
+++ b/drivers/thermal/rcar_thermal.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -81,8 +82,10 @@ struct rcar_thermal_priv {
# define rcar_force_update_temp(priv) 0
#endif
+#define USE_OF_THERMAL 1
static const struct of_device_id rcar_thermal_dt_ids[] = {
{ .compatible = "renesas,rcar-thermal", },
+ { .compatible = "renesas,rcar-gen2-thermal", .data = (void
*)USE_OF_THERMAL },
{},
};
MODULE_DEVICE_TABLE(of, rcar_thermal_dt_ids);
@@ -206,9 +209,8 @@ err_out_unlock:
return ret;
}
-static int rcar_thermal_get_temp(struct thermal_zone_device *zone, int *temp)
+static int rcar_thermal_get_current_temp(struct rcar_thermal_priv *priv, int
*temp)
{
- struct rcar_thermal_priv *priv = rcar_zone_to_priv(zone);
int tmp;
if (!rcar_has_irq_support(priv) || rcar_force_update_temp(priv)) {
@@ -234,6 +236,20 @@ static int rcar_thermal_get_temp(struct
thermal_zone_device *zone, int *temp)
return 0;
}
+static int rcar_thermal_of_get_temp(void *data, int *temp)
+{
+ struct rcar_thermal_priv *priv = data;
+
+ return rcar_thermal_get_current_temp(priv, temp);
+}
+
+static int rcar_thermal_get_temp(struct thermal_zone_device *zone, int *temp)
+{
+ struct rcar_thermal_priv *priv = rcar_zone_to_priv(zone);
+
+ return rcar_thermal_get_current_temp(priv, temp);
+}
+
static int rcar_thermal_get_trip_type(struct thermal_zone_device *zone,
int trip, enum thermal_trip_type *type)
{
@@ -290,6 +306,10 @@ static int rcar_thermal_notify(struct thermal_zone_device
*zone,
return 0;
}
+static const struct thermal_zone_of_device_ops rcar_thermal_zone_of_ops = {
+ .get_temp = rcar_thermal_of_get_temp,
+};
+
static struct thermal_zone_device_ops rcar_thermal_zone_ops = {
.get_temp = rcar_thermal_get_temp,
.get_trip_type = rcar_thermal_get_trip_type,
@@
Re: [PATCH] PCI: designware: bail out if host_init failed
Dear Bjorn,
On Wed, 25 Nov 2015 14:01:03 -0600
Bjorn Helgaas wrote:
> Hi Jisheng,
>
> On Thu, Nov 12, 2015 at 09:48:45PM +0800, Jisheng Zhang wrote:
> > There's no reason to continue the initialization such as configure
> > register, scan root bus etc. if customized host_init() failed. This
> > patch tries to check the host_init result, bail out if failed.
>
> This patch changes the (*host_init) return type and adds "return 0" to
> the host_init() implementations of ten different drivers, all to
> support a possible error in one driver.
>
> Is there any way to detect and handle the error in
> ls1021_pcie_host_init() earlier, maybe by doing the syscon_regmap
> lookup in ls_pcie_probe() instead of in the host_init() function?
>
> That would be even better because you wouldn't have to touch any of
> the other drivers, and you'd detect the error even earlier, before
> we've done any of the designware setup.
Sorry for being late. Got your point. The reason I made this patch is that:
I want to clk gate the pcie host to save power if the customized host_init()
report link training failure etc. For example: there's no pcie device in the
slot at all. But today, I have a different idea: the PCIE support hotplug,
so link training failure doesn't mean we should bail out, in fact we should
continue the initialization as current code does. So I think Jingoo made the
correct decision when implement the pcie designware interface. I want to drop
this patch.
Only one problem need your suggestions: how to save power when there's no device
, I.E clk gate the host, shutdown the pcie phy etc.
Any suggestions are appreciated!
Thanks in advance,
Jisheng
>
> Bjorn
>
> > Signed-off-by: Jisheng Zhang
> > ---
> > drivers/pci/host/pci-dra7xx.c | 4 +++-
> > drivers/pci/host/pci-exynos.c | 4 +++-
> > drivers/pci/host/pci-imx6.c| 4 +++-
> > drivers/pci/host/pci-keystone.c| 4 +++-
> > drivers/pci/host/pci-layerscape.c | 25 -
> > drivers/pci/host/pcie-designware.c | 7 +--
> > drivers/pci/host/pcie-designware.h | 2 +-
> > drivers/pci/host/pcie-spear13xx.c | 4 +++-
> > 8 files changed, 37 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
> > index 8c36880..b3160a1 100644
> > --- a/drivers/pci/host/pci-dra7xx.c
> > +++ b/drivers/pci/host/pci-dra7xx.c
> > @@ -149,7 +149,7 @@ static void dra7xx_pcie_enable_interrupts(struct
> > pcie_port *pp)
> >LEG_EP_INTERRUPTS);
> > }
> >
> > -static void dra7xx_pcie_host_init(struct pcie_port *pp)
> > +static int dra7xx_pcie_host_init(struct pcie_port *pp)
> > {
> > dw_pcie_setup_rc(pp);
> >
> > @@ -162,6 +162,8 @@ static void dra7xx_pcie_host_init(struct pcie_port *pp)
> > if (IS_ENABLED(CONFIG_PCI_MSI))
> > dw_pcie_msi_init(pp);
> > dra7xx_pcie_enable_interrupts(pp);
> > +
> > + return 0;
> > }
> >
> > static struct pcie_host_ops dra7xx_pcie_host_ops = {
> > diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
> > index 01095e1..57f370b 100644
> > --- a/drivers/pci/host/pci-exynos.c
> > +++ b/drivers/pci/host/pci-exynos.c
> > @@ -481,10 +481,12 @@ static int exynos_pcie_link_up(struct pcie_port *pp)
> > return 0;
> > }
> >
> > -static void exynos_pcie_host_init(struct pcie_port *pp)
> > +static int exynos_pcie_host_init(struct pcie_port *pp)
> > {
> > exynos_pcie_establish_link(pp);
> > exynos_pcie_enable_interrupts(pp);
> > +
> > + return 0;
> > }
> >
> > static struct pcie_host_ops exynos_pcie_host_ops = {
> > diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
> > index 22e8224..9a46680 100644
> > --- a/drivers/pci/host/pci-imx6.c
> > +++ b/drivers/pci/host/pci-imx6.c
> > @@ -425,7 +425,7 @@ static int imx6_pcie_establish_link(struct pcie_port
> > *pp)
> > return 0;
> > }
> >
> > -static void imx6_pcie_host_init(struct pcie_port *pp)
> > +static int imx6_pcie_host_init(struct pcie_port *pp)
> > {
> > imx6_pcie_assert_core_reset(pp);
> >
> > @@ -439,6 +439,8 @@ static void imx6_pcie_host_init(struct pcie_port *pp)
> >
> > if (IS_ENABLED(CONFIG_PCI_MSI))
> > dw_pcie_msi_init(pp);
> > +
> > + return 0;
> > }
> >
> > static void imx6_pcie_reset_phy(struct pcie_port *pp)
> > diff --git a/drivers/pci/host/pci-keystone.c
> > b/drivers/pci/host/pci-keystone.c
> > index 0aa81bd..2604571 100644
> > --- a/drivers/pci/host/pci-keystone.c
> > +++ b/drivers/pci/host/pci-keystone.c
> > @@ -250,7 +250,7 @@ static int keystone_pcie_fault(unsigned long addr,
> > unsigned int fsr,
> > return 0;
> > }
> >
> > -static void __init ks_pcie_host_init(struct pcie_port *pp)
> > +static int __init ks_pcie_host_init(struct pcie_port *pp)
> > {
> > struct keystone_pcie *ks_pcie = to_keystone_pcie(pp);
> > u32 val;
> > @@ -277,6 +277,8 @@ static void __init ks_pcie_host_init(struct pcie_port
> >
Re: [PSEUDOPATCH] rename is_compat_task
On Mon, Dec 7, 2015 at 9:15 PM, Al Viro wrote: > On Tue, Dec 08, 2015 at 06:01:48AM +0100, Ingo Molnar wrote: > >> Hm, so if Sparc has no notion of compat-ness of the system call then how >> does it >> implement runtime compat checks, such as AUDIT_ARCH et al? > > Badly. Things like compat_sys_ioctl() vs. ioctl() work (we use different > arrays of function pointers in 32bit and 64bit traps), but anything > dynamic assumes that things match the task. Not that we had a lot of > such dynamic checks, actually... I wouldn't take x86 as a shining example of how to do this, but it does mostly work. In 4.4, it's not even all that messy, modulo a bunch of checks that check the wrong condition (hence, in part, this proposal). --Andy -- 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 kernel] rcu: Define lockless version of list_for_each_entry_rcu
On Tue, Dec 08, 2015 at 04:20:03PM +1100, Paul Mackerras wrote: > On Sat, Dec 05, 2015 at 06:19:46PM -0800, Paul E. McKenney wrote: > > > > As in the following? (And yes, I was confused by the fact that the > > docbook header was in front of a differently-named macro!) > > That looks great! Have you committed to one of your branches? Indeed I have, though quite recently. Please see branch rcu/dev of: git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git Or, more specifically, this commit: 69b907297f4e If your testing goes well, I will push this into the upcoming merge window. Thanx, Paul -- 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 00/12] x86: Rewrite 64-bit syscall code
On Mon, Dec 7, 2015 at 8:42 PM, Ingo Molnar wrote: > > * Andy Lutomirski wrote: > >> On Mon, Dec 7, 2015 at 1:51 PM, Andy Lutomirski wrote: >> >> > This is kind of like the 32-bit and compat code, except that I preserved >> > the >> > fast path this time. I was unable to measure any significant performance >> > change on my laptop in the fast path. >> > >> > What do you all think? >> >> For completeness, if I zap the fast path entirely (see attached), I lose 20 >> cycles (148 cycles vs 128 cycles) on Skylake. Switching between movq and >> pushq >> for stack setup makes no difference whatsoever, interestingly. I haven't >> tried >> to figure out exactly where those 20 cycles go. > > So I asked for this before, and I'll do so again: could you please stick the > cycle > granular system call performance test into a 'perf bench' variant so that: > > 1) More people can run it all on various pieces of hardware and help out > quantify > the patches. > > 2) We can keep an eye on not regressing base system call performance in the > future, with a good in-tree testcase. > Is it okay if it's not particularly shiny or modular? The tool I'm using is here: https://git.kernel.org/cgit/linux/kernel/git/luto/misc-tests.git/tree/tight_loop/perf_self_monitor.c and I can certainly stick it into 'perf bench' pretty easily. Can I leave making it into a proper library to some future contributor? It's actually decently fancy. It allocates a perf self-monitoring instance that counts cycles, and then it takes a bunch of samples and discards any that flagged a context switch. It does some very rudimentary statistics on the rest. It's utterly devoid of a fancy UI, though. It works very well on native, and it works better than I had expected under KVM. (KVM traps RDPMC because neither Intel nor AMD has seen fit to provide any sensible way to virtualize RDPMC without exiting.) --Andy -- 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/
An issue about sp5100 watchdog
Hi all, I found an issue in some of AMD platforms about sp5100, that the MMIO address (0x51413120) is already used by System RAM (0010-7c2befff)... [ 29.928096] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver v0.05 [ 29.928302] sp5100_tco: PCI Vendor ID: 0x1022, Device ID: 0x790b, Revision ID: 0x4a [ 29.928319] sp5100_tco: Got 0x51413120 from indirect I/O [ 29.928323] sp5100_tco: MMIO address 0x51413120 already in use [ 29.928332] sp5100_tco: SBResource_MMIO is disabled(0xe000a0) [ 29.928333] sp5100_tco: failed to find MMIO address, giving up. 0010-7c2befff : System RAM 0100-017b1ab3 : Kernel code 017b1ab4-01d4ce7f : Kernel data 01ec4000-02008fff : Kernel bss 7c2bf000-7c8befff : reserved 7c8bf000-7cbbefff : ACPI Non-volatile Storage 7cbb6000-7cbb9fff : MSFT0101:00 7cbba000-7cbbdfff : MSFT0101:00 7cbbf000-7cbfefff : ACPI Tables 7cbff000-7cbf : System RAM 7cc0-7eff : reserved Any idea? Thanks, Rui -- 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:perf/core] perf/x86: Use INST_RETIRED.PREC_DIST for cycles: ppp
* Peter Zijlstra wrote: > On Sun, Dec 06, 2015 at 02:11:02PM +0100, Ingo Molnar wrote: > > > the symptom is that latest 'perf top' and 'perf record' produces no samples. > > > > So I've removed this commit and the related Skylake commit from -tip: > > > > 4576ceaa56a8 perf/x86: Use INST_RETIRED.PREC_DIST for cycles:ppp > > ac1e1d30cf90 perf/x86: Use INST_RETIRED.TOTAL_CYCLES_PS for cycles:pp for > > Skylake > > > > you need to do better testing next time around. Note: if you resubmit the > > patches, > > please also pick up the updates commit changelogs from the tip-bot emails, > > don't > > use your original changelogs. > > OK, so I need: > > lkml.kernel.org/r/1449177740-5422-1-git-send-email-a...@firstfloor.org > lkml.kernel.org/r/1449177740-5422-2-git-send-email-a...@firstfloor.org > > On my IVB because that keeps triggering that case with :ppp, other than > that this seems to work fine on IVB. > > I've also tried on SNB (which does not support the new :ppp thing) and > that too works. > > Sadly I do not have older hardware anymore :/ > > > Also, perf tools DTRT and will use :ppp by default if available. So I checked my NHM box with your latest queue and it now works correctly. Do you have any idea what the difference is/was? 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:locking/core] sched/cputime: Fix invalid gtime in proc
* Frederic Weisbecker wrote:
> On Fri, Dec 04, 2015 at 03:53:13AM -0800, tip-bot for Hiroshi Shimamoto wrote:
> > Commit-ID: 2541117b0cf79977fa11a0d6e17d61010677bd7b
> > Gitweb:
> > http://git.kernel.org/tip/2541117b0cf79977fa11a0d6e17d61010677bd7b
> > Author: Hiroshi Shimamoto
> > AuthorDate: Thu, 19 Nov 2015 16:47:28 +0100
> > Committer: Ingo Molnar
> > CommitDate: Fri, 4 Dec 2015 10:18:49 +0100
> >
> > sched/cputime: Fix invalid gtime in proc
> >
> > /proc/stats shows invalid gtime when the thread is running in guest.
> > When vtime accounting is not enabled, we cannot get a valid delta.
> > The delta is calculated with now - tsk->vtime_snap, but tsk->vtime_snap
> > is only updated when vtime accounting is runtime enabled.
> >
> > This patch makes task_gtime() just return gtime without computing the
> > buggy non-existing tickless delta when vtime accounting is not enabled.
> >
> > Use context_tracking_is_enabled() to check if vtime is accounting on
> > some cpu, in which case only we need to check the tickless delta. This
> > way we fix the gtime value regression on machines not running nohz full.
> >
> > The kernel config contains CONFIG_VIRT_CPU_ACCOUNTING_GEN=y and
> > CONFIG_NO_HZ_FULL_ALL=n and boot without nohz_full.
> >
> > I ran and stop a busy loop in VM and see the gtime in host.
> > Dump the 43rd field which shows the gtime in every second:
> >
> > # while :; do awk '{print $3" "$43}' /proc/3955/task/4014/stat; sleep
> > 1; done
> > S 4348
> > R 7064566
> > R 7064766
> > R 7064967
> > R 7065168
> > S 4759
> > S 4759
> >
> > During running busy loop, it returns large value.
> >
> > After applying this patch, we can see right gtime.
> >
> > # while :; do awk '{print $3" "$43}' /proc/10913/task/10956/stat;
> > sleep 1; done
> > S 5338
> > R 5365
> > R 5465
> > R 5566
> > R 5666
> > S 5726
> > S 5726
> >
> > Signed-off-by: Hiroshi Shimamoto
> > Signed-off-by: Frederic Weisbecker
> > Signed-off-by: Peter Zijlstra (Intel)
> > Cc: Chris Metcalf
> > Cc: Christoph Lameter
> > Cc: Linus Torvalds
> > Cc: Luiz Capitulino
> > Cc: Mike Galbraith
> > Cc: Paul E . McKenney
> > Cc: Paul E. McKenney
> > Cc: Peter Zijlstra
> > Cc: Rik van Riel
> > Cc: Thomas Gleixner
> > Link:
> > http://lkml.kernel.org/r/1447948054-28668-2-git-send-email-fweis...@gmail.com
> > Signed-off-by: Ingo Molnar
> > ---
>
> Thanks for applying the patchset!
>
> However we may want to backport this one, it's a regression fix affecting
> CONFIG_NO_HZ_FULL=y with nohz_full off (99% of many distros defaults).
>
> Thanks.
Absolutely, not sure why I forgot that tag - I added it for other recent fixes.
Greg, please consider applying this upstream fix to -stable as well:
2541117b0cf7 ("sched/cputime: Fix invalid gtime in proc")
Note, the commit will cherry-pick cleanly all the way back to v3.9 (released
2.5+
years ago), but it will only build on v3.14 and later kernels.
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/
[PATCH 8/8 v4] thermal: of-thermal: of_thermal_set_trip_temp() call thermal_zone_device_update()
From: Kuninori Morimoto of_thermal_set_trip_temp() updates trip temperature. It should call thermal_zone_device_update() immediately. Signed-off-by: Kuninori Morimoto --- v3 -> v4 - no change drivers/thermal/of-thermal.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c index 42b7d42..a1dd7b1 100644 --- a/drivers/thermal/of-thermal.c +++ b/drivers/thermal/of-thermal.c @@ -334,6 +334,8 @@ static int of_thermal_set_trip_temp(struct thermal_zone_device *tz, int trip, /* thermal framework should take care of data->mask & (1 << trip) */ data->trips[trip].temperature = temp; + thermal_zone_device_update(tz); + return 0; } -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/8 v4] ARM: shmobile: r8a7791: enable to use thermal-zone
From: Kuninori Morimoto
This patch enables to use thermal-zone on r8a7791.
This thermal sensor can measure temperature from -4 to 125000,
but over 117000 can be critical on this chip.
Thus, default critical temperature is now set as 115000 (this driver
is using 5000 steps) (Current critical temperature is using it as
9, but there is no big reason about it)
And it doesn't check thermal zone periodically (same as current
behavior). You can exchange it by modifying polling-delay[-passive]
property.
You can set trip temp if your kernel has CONFIG_THERMAL_WRITABLE_TRIPS,
but you need to take care to use it, since it will call
orderly_poweroff() it it reaches to the value.
echo $temp > /sys/class/thermal/thermal_zone0/trip_point_0_temp
Signed-off-by: Kuninori Morimoto
---
v3 -> v4
- modifing -> modifying
- reached -> reaches
- <115> -> <115000>
arch/arm/boot/dts/r8a7791.dtsi | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 3776974..9b37c80 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -69,6 +69,25 @@
};
};
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+
+ thermal-sensors = <>;
+
+ trips {
+ cpu-crit {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type= "critical";
+ };
+ };
+ cooling-maps {
+ };
+ };
+ };
+
gic: interrupt-controller@f1001000 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
@@ -185,12 +204,15 @@
power-domains = <_clocks>;
};
- thermal@e61f {
- compatible = "renesas,thermal-r8a7791", "renesas,rcar-thermal";
+ thermal: thermal@e61f {
+ compatible ="renesas,thermal-r8a7791",
+ "renesas,rcar-gen2-thermal",
+ "renesas,rcar-thermal";
reg = <0 0xe61f 0 0x14>, <0 0xe61f0100 0 0x38>;
interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
clocks = <_clks R8A7791_CLK_THERMAL>;
power-domains = <_clocks>;
+ #thermal-sensor-cells = <0>;
};
timer {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/8 v4] ARM: shmobile: r8a7790: enable to use thermal-zone
From: Kuninori Morimoto
This patch enables to use thermal-zone on r8a7790.
This thermal sensor can measure temperature from -4 to 125000,
but over 117000 can be critical on this chip.
Thus, default critical temperature is now set as 115000 (this driver
is using 5000 steps) (Current critical temperature is using it as
9, but there is no big reason about it)
And it doesn't check thermal zone periodically (same as current
behavior). You can exchange it by modifying polling-delay[-passive]
property.
You can set trip temp if your kernel has CONFIG_THERMAL_WRITABLE_TRIPS,
but you need to take care to use it, since it will call
orderly_poweroff() it it reaches to the value.
echo $temp > /sys/class/thermal/thermal_zone0/trip_point_0_temp
Signed-off-by: Kuninori Morimoto
---
v3 -> v4
- modifing -> modifying
- reached -> reaches
- <115> -> <115000>
arch/arm/boot/dts/r8a7790.dtsi | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 9f3036b..2203b97 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -112,6 +112,25 @@
};
};
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+
+ thermal-sensors = <>;
+
+ trips {
+ cpu-crit {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type= "critical";
+ };
+ };
+ cooling-maps {
+ };
+ };
+ };
+
gic: interrupt-controller@f1001000 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
@@ -202,12 +221,15 @@
power-domains = <_clocks>;
};
- thermal@e61f {
- compatible = "renesas,thermal-r8a7790", "renesas,rcar-thermal";
+ thermal: thermal@e61f {
+ compatible ="renesas,thermal-r8a7790",
+ "renesas,rcar-gen2-thermal",
+ "renesas,rcar-thermal";
reg = <0 0xe61f 0 0x14>, <0 0xe61f0100 0 0x38>;
interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
clocks = <_clks R8A7790_CLK_THERMAL>;
power-domains = <_clocks>;
+ #thermal-sensor-cells = <0>;
};
timer {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/8 v4] thermal: rcar: enable to use thermal-zone on DT
From: Kuninori Morimoto
This patch enables to use thermal-zone on DT if it was call as
"renesas,rcar-gen2-thermal".
Previous style is still supported by "renesas,rcar-thermal".
Signed-off-by: Kuninori Morimoto
---
v3 -> v4
- no change
.../devicetree/bindings/thermal/rcar-thermal.txt | 37 +-
drivers/thermal/rcar_thermal.c | 44 +++---
2 files changed, 74 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
index 332e625..601a54d 100644
--- a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
@@ -1,8 +1,9 @@
* Renesas R-Car Thermal
Required properties:
-- compatible : "renesas,thermal-", "renesas,rcar-thermal"
- as fallback.
+- compatible : "renesas,thermal-",
+ "renesas,rcar-gen2-thermal" (with thermal-zone) or
+ "renesas,rcar-thermal" (without thermal-zone) as
fallback.
Examples with soctypes are:
- "renesas,thermal-r8a73a4" (R-Mobile APE6)
- "renesas,thermal-r8a7779" (R-Car H1)
@@ -36,3 +37,35 @@ thermal@e61f {
0xe61f0300 0x38>;
interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
};
+
+Example (with thermal-zone):
+
+thermal-zones {
+ cpu_thermal: cpu-thermal {
+ polling-delay-passive = <1000>;
+ polling-delay = <5000>;
+
+ thermal-sensors = <>;
+
+ trips {
+ cpu-crit {
+ temperature = <115>;
+ hysteresis = <0>;
+ type= "critical";
+ };
+ };
+ cooling-maps {
+ };
+ };
+};
+
+thermal: thermal@e61f {
+ compatible ="renesas,thermal-r8a7790",
+ "renesas,rcar-gen2-thermal",
+ "renesas,rcar-thermal";
+ reg = <0 0xe61f 0 0x14>, <0 0xe61f0100 0 0x38>;
+ interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <_clks R8A7790_CLK_THERMAL>;
+ power-domains = <_clocks>;
+ #thermal-sensor-cells = <0>;
+};
diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
index 40c3ba5..d4d2661 100644
--- a/drivers/thermal/rcar_thermal.c
+++ b/drivers/thermal/rcar_thermal.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -81,8 +82,10 @@ struct rcar_thermal_priv {
# define rcar_force_update_temp(priv) 0
#endif
+#define USE_OF_THERMAL 1
static const struct of_device_id rcar_thermal_dt_ids[] = {
{ .compatible = "renesas,rcar-thermal", },
+ { .compatible = "renesas,rcar-gen2-thermal", .data = (void
*)USE_OF_THERMAL },
{},
};
MODULE_DEVICE_TABLE(of, rcar_thermal_dt_ids);
@@ -206,9 +209,8 @@ err_out_unlock:
return ret;
}
-static int rcar_thermal_get_temp(struct thermal_zone_device *zone, int *temp)
+static int rcar_thermal_get_current_temp(struct rcar_thermal_priv *priv, int
*temp)
{
- struct rcar_thermal_priv *priv = rcar_zone_to_priv(zone);
int tmp;
if (!rcar_has_irq_support(priv) || rcar_force_update_temp(priv)) {
@@ -234,6 +236,20 @@ static int rcar_thermal_get_temp(struct
thermal_zone_device *zone, int *temp)
return 0;
}
+static int rcar_thermal_of_get_temp(void *data, int *temp)
+{
+ struct rcar_thermal_priv *priv = data;
+
+ return rcar_thermal_get_current_temp(priv, temp);
+}
+
+static int rcar_thermal_get_temp(struct thermal_zone_device *zone, int *temp)
+{
+ struct rcar_thermal_priv *priv = rcar_zone_to_priv(zone);
+
+ return rcar_thermal_get_current_temp(priv, temp);
+}
+
static int rcar_thermal_get_trip_type(struct thermal_zone_device *zone,
int trip, enum thermal_trip_type *type)
{
@@ -290,6 +306,10 @@ static int rcar_thermal_notify(struct thermal_zone_device
*zone,
return 0;
}
+static const struct thermal_zone_of_device_ops rcar_thermal_zone_of_ops = {
+ .get_temp = rcar_thermal_of_get_temp,
+};
+
static struct thermal_zone_device_ops rcar_thermal_zone_ops = {
.get_temp = rcar_thermal_get_temp,
.get_trip_type = rcar_thermal_get_trip_type,
@@ -326,14 +346,20 @@ static void rcar_thermal_work(struct work_struct *work)
priv = container_of(work, struct rcar_thermal_priv, work.work);
- rcar_thermal_get_temp(priv->zone, );
+ ret = rcar_thermal_get_current_temp(priv, );
+ if (ret < 0)
+ return;
+
ret = rcar_thermal_update_temp(priv);
if (ret < 0)
return;
rcar_thermal_irq_enable(priv);
Re: [PATCH v4] block: create ioctl to discard-or-zeroout a range of blocks
On Mon, Dec 07, 2015 at 06:40:15PM -0800, Christoph Hellwig wrote:
> On Fri, Nov 13, 2015 at 02:01:43PM -0800, Darrick J. Wong wrote:
> > Create a new ioctl to expose the block layer's newfound ability to
> > issue either a zeroing discard, a WRITE SAME with a zero page, or a
> > regular write with the zero page. This BLKZEROOUT2 ioctl takes
> > {start, length, flags} as parameters. So far, the only flag available
> > is to enable the zeroing discard part -- without it, the call invokes
> > the old BLKZEROOUT behavior. start and length have the same meaning
> > as in BLKZEROOUT.
> >
> > Furthermore, because BLKZEROOUT2 issues commands directly to the
> > storage device, we must invalidate the page cache (as a regular
> > O_DIRECT write would do) to avoid returning stale cache contents at a
> > later time.
>
> So does BLKZEROOUT. Seems like adding the cache invalidation should
> be one patch and the ioctl another one. Otherwise this looks fine
> except that I kinda hate BLKZEROOUT2 name, but can't come up with
> anything better.
I should've sent the 4.4 version -- since the ioctl code was refactored into
separate functions and the new function modifies its arguments, I ended up
rewriting most of the function body just to set up the page cache invalidation.
(Ah, I see -- 4.4-rc1 came out and I forgot to resend.)
Blergh, v5 on its way...
--D
> --
> To unsubscribe from this list: send the line "unsubscribe linux-api" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/8 v4] thermal: rcar: retern error rcar_thermal_get_temp() if no ctemp update
From: Kuninori Morimoto
Current rcar_thermal_get_temp() returns latest temperature, but it might
not be updated if some HW issue happened. This means user might get
wrong temperature. This patch solved this issue.
Signed-off-by: Kuninori Morimoto
---
v3 -> v4
- "happend" -> "happened"
drivers/thermal/rcar_thermal.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
index 67b5216..40c3ba5 100644
--- a/drivers/thermal/rcar_thermal.c
+++ b/drivers/thermal/rcar_thermal.c
@@ -199,9 +199,9 @@ static int rcar_thermal_update_temp(struct
rcar_thermal_priv *priv)
dev_dbg(dev, "thermal%d %d -> %d\n", priv->id, priv->ctemp, ctemp);
- priv->ctemp = ctemp;
ret = 0;
err_out_unlock:
+ priv->ctemp = ctemp;
mutex_unlock(>lock);
return ret;
}
@@ -209,6 +209,7 @@ err_out_unlock:
static int rcar_thermal_get_temp(struct thermal_zone_device *zone, int *temp)
{
struct rcar_thermal_priv *priv = rcar_zone_to_priv(zone);
+ int tmp;
if (!rcar_has_irq_support(priv) || rcar_force_update_temp(priv)) {
int ret = rcar_thermal_update_temp(priv);
@@ -218,9 +219,18 @@ static int rcar_thermal_get_temp(struct
thermal_zone_device *zone, int *temp)
}
mutex_lock(>lock);
- *temp = MCELSIUS((priv->ctemp * 5) - 65);
+ tmp = MCELSIUS((priv->ctemp * 5) - 65);
mutex_unlock(>lock);
+ if ((tmp < MCELSIUS(-45)) || (tmp > MCELSIUS(125))) {
+ struct device *dev = rcar_priv_to_dev(priv);
+
+ dev_err(dev, "it couldn't measure temperature correctly\n");
+ return -EIO;
+ }
+
+ *temp = tmp;
+
return 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/8 v4] thermal: rcar: check every rcar_thermal_update_temp() return value
From: Kuninori Morimoto
Signed-off-by: Kuninori Morimoto
---
v3 -> v4
- add 1line between int <-> return
drivers/thermal/rcar_thermal.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
index ac8d1eb..a1a93f3 100644
--- a/drivers/thermal/rcar_thermal.c
+++ b/drivers/thermal/rcar_thermal.c
@@ -210,8 +210,12 @@ static int rcar_thermal_get_temp(struct
thermal_zone_device *zone, int *temp)
{
struct rcar_thermal_priv *priv = rcar_zone_to_priv(zone);
- if (!rcar_has_irq_support(priv) || rcar_force_update_temp(priv))
- rcar_thermal_update_temp(priv);
+ if (!rcar_has_irq_support(priv) || rcar_force_update_temp(priv)) {
+ int ret = rcar_thermal_update_temp(priv);
+
+ if (ret < 0)
+ return ret;
+ }
mutex_lock(>lock);
*temp = MCELSIUS((priv->ctemp * 5) - 65);
@@ -305,11 +309,15 @@ static void rcar_thermal_work(struct work_struct *work)
{
struct rcar_thermal_priv *priv;
int cctemp, nctemp;
+ int ret;
priv = container_of(work, struct rcar_thermal_priv, work.work);
rcar_thermal_get_temp(priv->zone, );
- rcar_thermal_update_temp(priv);
+ ret = rcar_thermal_update_temp(priv);
+ if (ret < 0)
+ return;
+
rcar_thermal_irq_enable(priv);
rcar_thermal_get_temp(priv->zone, );
@@ -427,7 +435,9 @@ static int rcar_thermal_probe(struct platform_device *pdev)
mutex_init(>lock);
INIT_LIST_HEAD(>list);
INIT_DELAYED_WORK(>work, rcar_thermal_work);
- rcar_thermal_update_temp(priv);
+ ret = rcar_thermal_update_temp(priv);
+ if (ret < 0)
+ goto error_unregister;
priv->zone = thermal_zone_device_register("rcar_thermal",
1, 0, priv,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/8 v4] thermal: rcar: check irq possibility in rcar_thermal_irq_xxx()
From: Kuninori Morimoto
Current rcar thermal driver sometimes checks irq possibility when it
calls rcar_thermal_irq_enable/disable(), but sometimes not.
This patch checks it inside rcar_thermal_irq_enable/disable().
Signed-off-by: Kuninori Morimoto
---
v3 -> v4
- no change
drivers/thermal/rcar_thermal.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
index a1a93f3..67b5216 100644
--- a/drivers/thermal/rcar_thermal.c
+++ b/drivers/thermal/rcar_thermal.c
@@ -298,6 +298,9 @@ static void _rcar_thermal_irq_ctrl(struct rcar_thermal_priv
*priv, int enable)
unsigned long flags;
u32 mask = 0x3 << rcar_id_to_shift(priv); /* enable Rising/Falling */
+ if (!rcar_has_irq_support(priv))
+ return;
+
spin_lock_irqsave(>lock, flags);
rcar_thermal_common_bset(common, INTMSK, mask, enable ? 0 : mask);
@@ -449,8 +452,7 @@ static int rcar_thermal_probe(struct platform_device *pdev)
goto error_unregister;
}
- if (rcar_has_irq_support(priv))
- rcar_thermal_irq_enable(priv);
+ rcar_thermal_irq_enable(priv);
list_move_tail(>list, >head);
@@ -496,8 +498,7 @@ static int rcar_thermal_remove(struct platform_device *pdev)
struct rcar_thermal_priv *priv;
rcar_thermal_for_each_priv(priv, common) {
- if (rcar_has_irq_support(priv))
- rcar_thermal_irq_disable(priv);
+ rcar_thermal_irq_disable(priv);
thermal_zone_device_unregister(priv->zone);
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/8 v4] thermal: rcar: move rcar_thermal_dt_ids to upside
From: Kuninori Morimoto
This patch is prepare for of-thermal support.
Signed-off-by: Kuninori Morimoto
---
v3 -> v4
- no change
drivers/thermal/rcar_thermal.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
index 5d4ae7d..ac8d1eb 100644
--- a/drivers/thermal/rcar_thermal.c
+++ b/drivers/thermal/rcar_thermal.c
@@ -81,6 +81,12 @@ struct rcar_thermal_priv {
# define rcar_force_update_temp(priv) 0
#endif
+static const struct of_device_id rcar_thermal_dt_ids[] = {
+ { .compatible = "renesas,rcar-thermal", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, rcar_thermal_dt_ids);
+
/*
* basic functions
*/
@@ -491,12 +497,6 @@ static int rcar_thermal_remove(struct platform_device
*pdev)
return 0;
}
-static const struct of_device_id rcar_thermal_dt_ids[] = {
- { .compatible = "renesas,rcar-thermal", },
- {},
-};
-MODULE_DEVICE_TABLE(of, rcar_thermal_dt_ids);
-
static struct platform_driver rcar_thermal_driver = {
.driver = {
.name = "rcar_thermal",
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/8 v4] enable to use thermal-zone on r8a7790/1
Hi These are v4 of thermal-zone support for r8a7790/r8a7791. Mainly, it cares return value of get_temp() I think 8) is needed on of-thermal (?) Kuninori Morimoto (8): 1) thermal: rcar: move rcar_thermal_dt_ids to upside 2) thermal: rcar: check every rcar_thermal_update_temp() return value 3) thermal: rcar: check irq possibility in rcar_thermal_irq_xxx() 4) thermal: rcar: retern error rcar_thermal_get_temp() if no ctemp update 5) thermal: rcar: enable to use thermal-zone on DT 6) ARM: shmobile: r8a7790: enable to use thermal-zone 7) ARM: shmobile: r8a7791: enable to use thermal-zone 8) thermal: of-thermal: of_thermal_set_trip_temp() call thermal_zone_device_update() Documentation/devicetree/bindings/thermal/rcar-thermal.txt | 37 +++-- arch/arm/boot/dts/r8a7790.dtsi | 26 -- arch/arm/boot/dts/r8a7791.dtsi | 26 -- drivers/thermal/of-thermal.c | 2 ++ drivers/thermal/rcar_thermal.c | 96 +++- 5 files changed, 160 insertions(+), 27 deletions(-) Best regards --- Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] RTC: RK808: Work around hardware bug on November 31st
In Fuzhou, China, the month of November seems to be having 31 days.
That's nice and all (I'm sure you can get a lot more done in a year that
way), but back here in other parts of the world we are not so lucky.
Therefore, we need to compensate for these extra days existing only in
the RTC's imagination when reading the time and dealing with alarms.
This patch is not a perfect workaround -- it only keeps the time stable
as long as the system is running or suspended. If the system is fully
shut down in November and only booted back up in December, the system
time may be incorrect and alarms that had been set before the shutdown
may fire on the wrong day. We're trying to catch and recover from this
by reading the RTC's last "shadow timestamp" (which only gets resynced
when transitioning the GET_TIME control bit) to figure out when the
system was shut down, but this is only reliable if no other code (e.g.
firmware) has read the RTC in-between.
Basic idea for the workaround:
- Whenever we set the time, we assume that timestamp to be correct
(synced to the real world). We store a copy of it in memory as an
anchor point (where we know our calendar matched the real world).
- Whenever we read the time, we can tell how many days of desync we have
by counting November/December transitions between the anchor timestamp
and the time read from the hardware. We adjust the hardware clock
accordingly to get back in sync (which also resets the anchor time).
- Whenever we set an alarm, we adjust the alarm time backwards by the
amount of days that we know we will lag behind at that point (by
counting the November/December transitions between our anchor point
and the alarm). This way, we will wake up on the right real world date
even though we cannot make adjustments while suspended.
- Whenever we read an alarm, we do the opposite (forward) adjustment for
the returned result to keep our outside interface free from this
madness (callers expect to be able to read back the alarm they wrote).
- Whenever we set the system time (which adjusts the anchor point), we
read out the (adjusted) alarm time beforehand and write it (newly
adjusted) back afterwards. This way, system time and alarm time will
always stay on the same calendar (as long as we're able to keep track
of our anchor point, at least).
Signed-off-by: Julius Werner
---
drivers/rtc/rtc-rk808.c | 282
1 file changed, 190 insertions(+), 92 deletions(-)
diff --git a/drivers/rtc/rtc-rk808.c b/drivers/rtc/rtc-rk808.c
index 91ca0bc..2a6cd6f 100644
--- a/drivers/rtc/rtc-rk808.c
+++ b/drivers/rtc/rtc-rk808.c
@@ -54,103 +54,30 @@ struct rk808_rtc {
struct rk808 *rk808;
struct rtc_device *rtc;
int irq;
+ struct rtc_time anchor_time;/* Last sync point with real world */
};
-/* Read current time and date in RTC */
-static int rk808_rtc_readtime(struct device *dev, struct rtc_time *tm)
+/*
+ * RK808 has a hardware bug causing it to count 31 days in November. This
+ * function can calculate the amount of days that code needs to adjust for
+ * between two timestamps to compensate for this.
+ */
+static int nov31st_transitions(struct rtc_time *from, struct rtc_time *to)
{
- struct rk808_rtc *rk808_rtc = dev_get_drvdata(dev);
- struct rk808 *rk808 = rk808_rtc->rk808;
- u8 rtc_data[NUM_TIME_REGS];
- int ret;
-
- /* Force an update of the shadowed registers right now */
- ret = regmap_update_bits(rk808->regmap, RK808_RTC_CTRL_REG,
-BIT_RTC_CTRL_REG_RTC_GET_TIME,
-BIT_RTC_CTRL_REG_RTC_GET_TIME);
- if (ret) {
- dev_err(dev, "Failed to update bits rtc_ctrl: %d\n", ret);
- return ret;
- }
-
- /*
-* After we set the GET_TIME bit, the rtc time can't be read
-* immediately. So we should wait up to 31.25 us, about one cycle of
-* 32khz. If we clear the GET_TIME bit here, the time of i2c transfer
-* certainly more than 31.25us: 16 * 2.5us at 400kHz bus frequency.
-*/
- ret = regmap_update_bits(rk808->regmap, RK808_RTC_CTRL_REG,
-BIT_RTC_CTRL_REG_RTC_GET_TIME,
-0);
- if (ret) {
- dev_err(dev, "Failed to update bits rtc_ctrl: %d\n", ret);
- return ret;
- }
+ int extra_days = to->tm_year - from->tm_year;
- ret = regmap_bulk_read(rk808->regmap, RK808_SECONDS_REG,
- rtc_data, NUM_TIME_REGS);
- if (ret) {
- dev_err(dev, "Failed to bulk read rtc_data: %d\n", ret);
- return ret;
- }
+ /* Avoid adjusting anything for uninitialized timestamps */
+ if (from->tm_mday == 0 || to->tm_mday == 0)
+ return 0;
- tm->tm_sec = bcd2bin(rtc_data[0] & SECONDS_REG_MSK);
- tm->tm_min =
Re: [PATCH kernel] rcu: Define lockless version of list_for_each_entry_rcu
On Sat, Dec 05, 2015 at 06:19:46PM -0800, Paul E. McKenney wrote: > > As in the following? (And yes, I was confused by the fact that the > docbook header was in front of a differently-named macro!) > > Thanx, Paul That looks great! Have you committed to one of your branches? Thanks, Paul. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st
> Still, you're right that adding the GET_TIME check wouldn't hurt... at > worst it just does nothing. I'll try it out. Hmm... so it basically works (when you hack the RTC read out of the firmware), but only on reboot for some reason (which makes it way less useful). After a full power off I'm reading only zeroes out until I transition GET_TIME again. My guess would be that these shadow registers are not in the RTC power well... I've talked to Alex and he said that we disable the RK808's main power source in S5, but that devices without an EC (e.g. phones) would likely leave it on. So I guess it's still a good extra workaround to keep in the code, but it will never help on Chromebooks (and there's no point in hacking up our firmware for it). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/3] reduce latency of direct async compaction
On Tue, Dec 08, 2015 at 09:41:18AM +0900, Joonsoo Kim wrote:
> On Mon, Dec 07, 2015 at 04:59:56PM +0800, Aaron Lu wrote:
> > On Mon, Dec 07, 2015 at 04:35:24PM +0900, Joonsoo Kim wrote:
> > > It looks like overhead still remain. I guess that migration scanner
> > > would call pageblock_pfn_to_page() for more extended range so
> > > overhead still remain.
> > >
> > > I have an idea to solve his problem. Aaron, could you test following patch
> > > on top of base? It tries to skip calling pageblock_pfn_to_page()
> >
> > It doesn't apply on top of 25364a9e54fb8296837061bf684b76d20eec01fb
> > cleanly, so I made some changes to make it apply and the result is:
> > https://github.com/aaronlu/linux/commit/cb8d05829190b806ad3948ff9b9e08c8ba1daf63
>
> Yes, that's okay. I made it on my working branch but it will not result in
> any problem except applying.
>
> >
> > There is a problem occured right after the test starts:
> > [ 58.080962] BUG: unable to handle kernel paging request at
> > ea008218
> > [ 58.089124] IP: [] compaction_alloc+0xf9/0x270
> > [ 58.096109] PGD 107ffd6067 PUD 207f7d5067 PMD 0
> > [ 58.101569] Oops: [#1] SMP
>
> I did some mistake. Please test following patch. It is also made
> on my working branch so you need to resolve conflict but it would be
> trivial.
>
> I inserted some logs to check whether zone is contiguous or not.
> Please check that normal zone is set to contiguous after testing.
Yes it is contiguous, but unfortunately, the problem remains:
[ 56.536930] check_zone_contiguous: Normal
[ 56.543467] check_zone_contiguous: Normal: contiguous
[ 56.549640] BUG: unable to handle kernel paging request at ea008218
[ 56.557717] IP: [] compaction_alloc+0xf9/0x270
[ 56.564719] PGD 107ffd6067 PUD 207f7d5067 PMD 0
Full dmesg attached.
Thanks,
Aaron
>
> Thanks.
>
> -->8--
> From 4a1a08d8ab3fb165b87ad2ec0a2000ff6892330f Mon Sep 17 00:00:00 2001
> From: Joonsoo Kim
> Date: Mon, 7 Dec 2015 14:51:42 +0900
> Subject: [PATCH] mm/compaction: Optimize pageblock_pfn_to_page() for
> contiguous zone
>
> Signed-off-by: Joonsoo Kim
> ---
> include/linux/mmzone.h | 1 +
> mm/compaction.c| 54
> +-
> 2 files changed, 54 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index e23a9e7..573f9a9 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -521,6 +521,7 @@ struct zone {
> #endif
>
> #if defined CONFIG_COMPACTION || defined CONFIG_CMA
> + int contiguous;
> /* Set to true when the PG_migrate_skip bits should be cleared */
> boolcompact_blockskip_flush;
> #endif
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 67b8d90..cb5c7a2 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -88,7 +88,7 @@ static inline bool migrate_async_suitable(int migratetype)
> * the first and last page of a pageblock and avoid checking each individual
> * page in a pageblock.
> */
> -static struct page *pageblock_pfn_to_page(unsigned long start_pfn,
> +static struct page *__pageblock_pfn_to_page(unsigned long start_pfn,
> unsigned long end_pfn, struct zone *zone)
> {
> struct page *start_page;
> @@ -114,6 +114,56 @@ static struct page *pageblock_pfn_to_page(unsigned long
> start_pfn,
> return start_page;
> }
>
> +static inline struct page *pageblock_pfn_to_page(unsigned long start_pfn,
> + unsigned long end_pfn, struct zone *zone)
> +{
> + if (zone->contiguous == 1)
> + return pfn_to_page(start_pfn);
> +
> + return __pageblock_pfn_to_page(start_pfn, end_pfn, zone);
> +}
> +
> +static void check_zone_contiguous(struct zone *zone)
> +{
> + unsigned long block_start_pfn = zone->zone_start_pfn;
> + unsigned long block_end_pfn;
> + unsigned long pfn;
> +
> + /* Already checked */
> + if (zone->contiguous)
> + return;
> +
> + printk("%s: %s\n", __func__, zone->name);
> + block_end_pfn = ALIGN(block_start_pfn + 1, pageblock_nr_pages);
> + for (; block_start_pfn < zone_end_pfn(zone);
> + block_start_pfn = block_end_pfn,
> + block_end_pfn += pageblock_nr_pages) {
> +
> + block_end_pfn = min(block_end_pfn, zone_end_pfn(zone));
> +
> + if (!__pageblock_pfn_to_page(block_start_pfn,
> + block_end_pfn, zone)) {
> + /* We have hole */
> + zone->contiguous = -1;
> + printk("%s: %s: uncontiguous\n", __func__,
> zone->name);
> + return;
> + }
> +
> + /* Check validity of pfn within pageblock */
> + for (pfn = block_start_pfn; pfn < block_end_pfn; pfn++) {
> + if
Re: [PSEUDOPATCH] rename is_compat_task
On Tue, Dec 08, 2015 at 06:01:48AM +0100, Ingo Molnar wrote: > Hm, so if Sparc has no notion of compat-ness of the system call then how does > it > implement runtime compat checks, such as AUDIT_ARCH et al? Badly. Things like compat_sys_ioctl() vs. ioctl() work (we use different arrays of function pointers in 32bit and 64bit traps), but anything dynamic assumes that things match the task. Not that we had a lot of such dynamic checks, actually... -- 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:perf/core] perf hists browser: Add NULL pointer check to prevent crash
Commit-ID: 837eeb7569bf2b3bd3b1b82e0e61edb19811036e
Gitweb: http://git.kernel.org/tip/837eeb7569bf2b3bd3b1b82e0e61edb19811036e
Author: Wang Nan
AuthorDate: Mon, 7 Dec 2015 02:35:45 +
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 7 Dec 2015 12:02:11 -0300
perf hists browser: Add NULL pointer check to prevent crash
Before this patch we can trigger a segfault by following steps:
Step 0: Use 'perf record' to generate a perf.data without callchain
Step 1: perf report
Step 2: Use UP/DOWN to select an entry, don't press 'ENTER'
Step 3: Use '/' to filter symbols, use a filter which returns
empty result
Step 4: Press 'ENTER' (notice here that the old selection is still
there. This is another problem)
Step 5: Press 'ENTER' to annotate that symbol
Step 6: Press 'LEFT' to go out.
Result: segfault:
perf: Segmentation fault
backtrace
/home/wangnan/perf[0x53e568]
/lib64/libc.so.6(+0x3545f)[0x7fba75d3245f]
/home/wangnan/perf[0x537516]
/home/wangnan/perf[0x533fef]
/home/wangnan/perf[0x53b347]
/home/wangnan/perf(perf_evlist__tui_browse_hists+0x96)[0x53d206]
/home/wangnan/perf(cmd_report+0x1b9f)[0x442c7f]
/home/wangnan/perf[0x47efa2]
/home/wangnan/perf(main+0x5f5)[0x432fa5]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x7fba75d1ebd4]
/home/wangnan/perf[0x4330d4]
This is because in this case 'nd' could be NULL in
ui_browser__hists_seek(), but that function never checks it.
This patch adds checker for potential NULL pointer in that function.
After this patch the above steps won't segfault.
Signed-off-by: Wang Nan
Tested-by: Arnaldo Carvalho de Melo
Cc: Namhyung Kim
Cc: Zefan Li
Cc: pi3or...@163.com
Link:
http://lkml.kernel.org/r/1449455746-41952-3-git-send-email-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/ui/browsers/hists.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index fa9eb92..932e13d 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1033,6 +1033,9 @@ static void ui_browser__hists_seek(struct ui_browser
*browser,
* and stop when we printed enough lines to fill the screen.
*/
do_offset:
+ if (!nd)
+ return;
+
if (offset > 0) {
do {
h = rb_entry(nd, struct hist_entry, rb_node);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf hists browser: Fix segfault if use symbol filter in cmdline
Commit-ID: 4938cf0c7a62025bbfbf3db7bcdcc2c33312bedb Gitweb: http://git.kernel.org/tip/4938cf0c7a62025bbfbf3db7bcdcc2c33312bedb Author: Wang Nan AuthorDate: Mon, 7 Dec 2015 02:35:44 + Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 7 Dec 2015 12:02:35 -0300 perf hists browser: Fix segfault if use symbol filter in cmdline If feed perf a symbol filter in cmdline and the result is empty, pressing 'Enter' in the hist browser causes crash: # ./perf report perf.data <-- Common mistake for beginners Then press 'Enter': perf: Segmentation fault backtrace /home/wangnan/perf[0x53e578] /lib64/libc.so.6(+0x3545f)[0x7f76bafe045f] /home/wangnan/perf[0x539dd4] /home/wangnan/perf(perf_evlist__tui_browse_hists+0x96)[0x53d216] /home/wangnan/perf(cmd_report+0x1b9f)[0x442c7f] /home/wangnan/perf[0x47efa2] /home/wangnan/perf(main+0x5f5)[0x432fa5] /lib64/libc.so.6(__libc_start_main+0xf4)[0x7f76bafccbd4] /home/wangnan/perf[0x4330d4] This is because 'perf.data' is interpreted as a symbol filter, and the result is empty, so selection is empty. However, hist_browser__toggle_fold() forgets to check it. This patch simply return false when selection is NULL. Signed-off-by: Wang Nan Acked-by: Namhyung Kim Tested-by: Arnaldo Carvalho de Melo Cc: Zefan Li Cc: pi3or...@163.com Link: http://lkml.kernel.org/r/1449455746-41952-2-git-send-email-wangn...@huawei.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/ui/browsers/hists.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c index 84c8251..81def6c3 100644 --- a/tools/perf/ui/browsers/hists.c +++ b/tools/perf/ui/browsers/hists.c @@ -298,6 +298,9 @@ static bool hist_browser__toggle_fold(struct hist_browser *browser) struct callchain_list *cl = container_of(ms, struct callchain_list, ms); bool has_children; + if (!he || !ms) + return false; + if (ms == >ms) has_children = hist_entry__toggle_fold(he); else -- 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:perf/core] perf hists browser: Reset selection when refresh
Commit-ID: 979d2cac1144da6b25334a8572c80cde9662105c
Gitweb: http://git.kernel.org/tip/979d2cac1144da6b25334a8572c80cde9662105c
Author: Wang Nan
AuthorDate: Mon, 7 Dec 2015 02:35:46 +
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 7 Dec 2015 12:02:12 -0300
perf hists browser: Reset selection when refresh
With the following steps:
Step 1: perf report
Step 2: Use UP/DOWN to select an entry, don't press 'ENTER'
Step 3: Use '/' to filter symbols, use a filter which returns
empty result
Step 4: Press 'ENTER'
We see that, even if we have filtered all the symbols (and the main
interface is empty), pressing 'ENTER' still selects one symbol. This
behavior surprises the user.
This patch resets browser->{he_,}selection in hist_browser__refresh()
and lets it choose default selection. In this case
browser->{he_,}selection keeps NULL so user won't see annotation item in
menu.
Signed-off-by: Wang Nan
Acked-by: Namhyung Kim
Tested-by: Arnaldo Carvalho de Melo
Cc: Zefan Li
Cc: pi3or...@163.com
Link:
http://lkml.kernel.org/r/1449455746-41952-4-git-send-email-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/ui/browsers/hists.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 932e13d..84c8251 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -928,6 +928,8 @@ static unsigned int hist_browser__refresh(struct ui_browser
*browser)
}
ui_browser__hists_init_top(browser);
+ hb->he_selection = NULL;
+ hb->selection = NULL;
for (nd = browser->top; nd; nd = rb_next(nd)) {
struct hist_entry *h = rb_entry(nd, struct hist_entry, rb_node);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
next-20151207 - crash in IPv6 code
Seen this in 2 boots out of two on next-20151207 when IPV6 networking was available. It was stable when no net was available. Also, next-20161127 is OK. Haven't bisected it yet - this ring any bells? [ 92.231022] BUG: unable to handle kernel NULL pointer dereference at (null) [ 92.231035] IP: [] nf_ct_frag6_gather+0x81b/0xba0 [ 92.231046] PGD 0 [ 92.231050] Oops: [#1] PREEMPT SMP [ 92.231166] Call Trace: [ 92.231170] [ 92.231196] [] ipv6_defrag+0x66/0x80 [ 92.231206] [] nf_iterate+0x62/0x80 [ 92.231216] [] nf_hook_slow+0xba/0x1b0 [ 92.231225] [] ? nf_hook_slow+0x5/0x1b0 [ 92.231235] [] ipv6_rcv+0x83d/0x8d0 [ 92.231242] [] ? ipv6_rcv+0x3e/0x8d0 [ 92.231251] [] ? ip6_input_finish+0x7e0/0x7e0 [ 92.231260] [] __netif_receive_skb_core+0x60a/0xd70 [ 92.231269] [] __netif_receive_skb+0x20/0x90 [ 92.231278] [] netif_receive_skb_internal+0x70/0x1f0 [ 92.231285] [] ? netif_receive_skb_internal+0x25/0x1f0 [ 92.231292] [] ? eth_type_trans+0x11b/0x200 [ 92.231300] [] netif_receive_skb+0x59/0x170 [ 92.231308] [] ieee80211_deliver_skb+0x120/0x180 [ 92.231315] [] ieee80211_rx_handlers+0x2762/0x29f0 [ 92.231324] [] ? skb_queue_tail+0x20/0x50 [ 92.231335] [] ? do_raw_spin_lock+0x148/0x1e0 [ 92.231342] [] ? trace_hardirqs_on_caller+0x16/0x1b0 [ 92.231358] [] ieee80211_prepare_and_rx_handle+0x24e/0xa80 [ 92.231365] [] ? ieee80211_rx_napi+0x23a/0xf00 [ 92.231373] [] ieee80211_rx_napi+0x537/0xf00 [ 92.231380] [] ? ieee80211_rx_napi+0x23a/0xf00 [ 92.231391] [] ieee80211_tasklet_handler+0xc5/0xd0 [ 92.231401] [] tasklet_action+0x1d5/0x220 [ 92.231409] [] __do_softirq+0xec/0x5a0 [ 92.231417] [] irq_exit+0xd4/0xe0 [ 92.231426] [] do_IRQ+0x6a/0x120 [ 92.231434] [] common_interrupt+0x89/0x89 [ 92.231440] [ 92.231450] [] ? cpuidle_enter_state+0x1ac/0x410 [ 92.231458] [] ? trace_hardirqs_on+0xd/0x10 [ 92.231466] [] ? cpuidle_enter_state+0x1b7/0x410 [ 92.231476] [] ? cpuidle_enter_state+0x1ac/0x410 [ 92.231485] [] cpuidle_enter+0x17/0x20 [ 92.231494] [] cpu_startup_entry+0x48d/0x520 [ 92.231503] [] start_secondary+0x154/0x170 [ 92.231510] Code: 8b fd ff ff 48 8b 13 48 89 10 49 8b 0e 49 39 ce 0f 84 80 01 00 00 48 8b 11 48 39 d3 0f 84 71 01 00 00 49 39 d6 0f 84 6b 01 00 00 <48 > 8b 0a 48 39 cb 0f 84 59 01 00 00 48 89 ca 49 39 d6 75 ec e9 [ 92.231685] RIP [] nf_ct_frag6_gather+0x81b/0xba0 [ 92.231698] RSP [ 92.231704] CR2: [ 92.231714] ---[ end trace 62089aaf8d90e56a ]--- [ 94.678192] Kernel panic - not syncing: Fatal exception in interrupt [ 94.678228] Kernel Offset: 0x3300 from 0x8100 (relocation range: 0x8000-0xbfff) pgpC7rpUsCp9N.pgp Description: PGP signature
Re: [GIT PULL 0/5] perf/urgent fixes
* Arnaldo Carvalho de Melo wrote: > From: Arnaldo Carvalho de Melo > > Hi Ingo, > > Please consider applying, > > - Arnaldo > > The following changes since commit 4e93ad601a4308d4a67673c81556580817d56940: > > perf: Do not send exit event twice (2015-12-06 12:54:49 +0100) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git > tags/perf-urgent-for-mingo > > for you to fetch changes up to 4938cf0c7a62025bbfbf3db7bcdcc2c33312bedb: > > perf hists browser: Fix segfault if use symbol filter in cmdline > (2015-12-07 12:02:35 -0300) > > > perf/urgent fixes: > > User visible: > > - Fix showing the running kernel build id using: (Michael Petlan) > > $ perf buildid-list -k > 03c2a89c595616188f02f0282762a75b47069bc0 > > - hists browser (report, top) symbol filter segfault fixes (Wang Nan) > > Signed-off-by: Arnaldo Carvalho de Melo > > > Michael Petlan (2): > perf buildid-list: Show running kernel build id fix > perf buildid-list: Fix return value of perf buildid-list -k > > Wang Nan (3): > perf hists browser: Add NULL pointer check to prevent crash > perf hists browser: Reset selection when refresh > perf hists browser: Fix segfault if use symbol filter in cmdline > > tools/perf/builtin-buildid-list.c | 2 +- > tools/perf/ui/browsers/hists.c| 8 > tools/perf/util/build-id.c| 2 +- > 3 files changed, 10 insertions(+), 2 deletions(-) Pulled, thanks a lot Arnaldo! I also merged the fixes into perf/core and pushed it all out, so you can base subsequent changes on top of the merged result. 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 7/8 v3] ARM: shmobile: r8a7791: enable to use thermal-zone
Hi Khiem > Hi Morimoto-san, > > Thanks for your patch. > I have same comments as patch 0006. Thanks, will fix in v4 -- 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: [PSEUDOPATCH] rename is_compat_task
* Al Viro wrote: > On Tue, Dec 08, 2015 at 05:36:49AM +0100, Ingo Molnar wrote: > > > So are there any deep objections to doing this rename in a single, quick, > > pain-minimized fashion right at the end of the next merge window, when the > > amount of pending patches in various maintainer trees is at a cyclical > > minimum? We can also keep an is_compat_task() migratory define for one more > > cycle just in case. > > Again, what about sparc? There we have both 64bit and 32bit syscalls > possible > to issue from the same process *and* no indication which trap had been used; > how > do you implement is_compat_syscall() there? There's a TIF_32BIT, which is > used > by mmap() and friends, signal delivery, etc., but that's not a matter of > which > syscall flavour had been issued. Said that, arch/sparc doesn't use > is_compat_task(); it's open-coded everywhere... Hm, so if Sparc has no notion of compat-ness of the system call then how does it implement runtime compat checks, such as AUDIT_ARCH et al? 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 4.2 000/124] 4.2.7-stable review
On Mon, Dec 07, 2015 at 09:54:50AM -0500, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.2.7 release.
> There are 124 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Dec 9 14:48:34 UTC 2015.
> Anything received after that time might be too late.
Apart from the failures Guenter reported, for me tile and tilegx
allmodconfig fails. Its known failure. Fix is:
3a48d13d76c0 ("tile: fix build failure")
Build logs at:
https://travis-ci.org/sudipm-mukherjee/stable/builds/95370057
regards
sudip
--
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: Fixing full name in patchwork
On Mon, Dec 07, 2015 at 08:03:54PM +0200, Kalle Valo wrote: > Hi Sudip, > > Sudip Mukherjee writes: > > > We were dereferencing cmd first and checking for NULL later. Lets first > > check for NULL. > > > > Signed-off-by: Sudip Mukherjee > > I noticed that your name in git log is not your full name: > > commit 0a38c8e1b592c16d959da456f425053e323a5153 > Author: sudip > Date: Tue Nov 24 13:51:38 2015 +0530 > > This is because for some reason in patchwork your fullname is just > "sudip": > > https://patchwork.kernel.org/patch/7688171/ > > Could you please fix your name in patchwork so that in the future we can > use your correct full name? The problem is that I don't know exactly how > to do this but it should be possible because I remember someone else > having a similar problem and he was able to fix it. Hi Kalle, I have also noticed the patch. Anyway, I have created a profile in patchwork and given full name. Hopefully that should solve the problem. regards sudip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] nvmem: mediatek: Add Mediatek EFUSE driver
On Thu, Nov 19, 2015 at 6:46 PM, Andrew-CT Chen wrote: > Add Mediatek EFUSE driver to access hardware data like > thermal sensor calibration or HDMI impedance. > > Signed-off-by: Andrew-CT Chen > --- > drivers/nvmem/Kconfig | 11 ++ > drivers/nvmem/Makefile| 2 ++ > drivers/nvmem/mtk-efuse.c | 89 > +++ > 3 files changed, 102 insertions(+) > create mode 100644 drivers/nvmem/mtk-efuse.c > > diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig > index bc4ea58..ea7ec17 100644 > --- a/drivers/nvmem/Kconfig > +++ b/drivers/nvmem/Kconfig > @@ -36,6 +36,17 @@ config NVMEM_MXS_OCOTP > This driver can also be built as a module. If so, the module > will be called nvmem-mxs-ocotp. > > +config MTK_EFUSE Nit: I think this entry should be between NVMEM_IMX_OCOTP and NVMEM_MXS_OCOTP (looks like NVMEM_ prefix is ignored in the ordering). > [snip] The rest looks good. -- 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: [PSEUDOPATCH] rename is_compat_task
On Tue, Dec 08, 2015 at 05:36:49AM +0100, Ingo Molnar wrote: > So are there any deep objections to doing this rename in a single, quick, > pain-minimized fashion right at the end of the next merge window, when the > amount > of pending patches in various maintainer trees is at a cyclical minimum? We > can > also keep an is_compat_task() migratory define for one more cycle just in > case. Again, what about sparc? There we have both 64bit and 32bit syscalls possible to issue from the same process *and* no indication which trap had been used; how do you implement is_compat_syscall() there? There's a TIF_32BIT, which is used by mmap() and friends, signal delivery, etc., but that's not a matter of which syscall flavour had been issued. Said that, arch/sparc doesn't use is_compat_task(); it's open-coded everywhere... -- 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 Dec 8
Hi all, Changes since 20151207: Undropped tree: cgroup The vfs tree gained a conflict against the s390 tree and a build failure so I used the version from next-20151207. The drm-misc tree gained a build failure so I used the version from next-20151207. The gpio tree still had its build failure, so I used the version from next-20151127 for today. Non-merge commits (relative to Linus' tree): 4217 4833 files changed, 174427 insertions(+), 73667 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig (this fails its final link) and pseries_le_defconfig and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 231 trees (counting Linus' and 36 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (62ea1ec5e17f Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost) Merging fixes/master (25cb62b76430 Linux 4.3-rc5) Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on module install) Merging arc-current/for-curr (6d1a2adef782 ARC: [axs10x] cap ethernet phy to 100 Mbit/sec) Merging arm-current/fixes (db0ad024543c ARM: fix uaccess_with_memcpy() with SW_DOMAIN_PAN) Merging m68k-current/for-linus (21d380e54c30 m68k: Wire up mlock2) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-fixes/fixes (7f821fc9c77a powerpc/tm: Check for already reclaimed tasks) Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2) Merging sparc/master (2c302e7e4105 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc) Merging net/master (4675390a9e71 ethernet: aurora: AURORA_NB8800 should depend on HAS_DMA) Merging ipsec/master (a8a572a6b5f2 xfrm: dst_entries_init() per-net dst_ops) Merging ipvs/master (8e662164abb4 netfilter: nfnetlink_queue: avoid harmless unnitialized variable warnings) Merging wireless-drivers/master (eeec5d0ef7ee rtlwifi: rtl8821ae: Fix lockups on boot) Merging mac80211/master (c1df932c0574 mac80211: fix off-channel mgmt-tx uninitialized variable usage) Merging sound-current/for-linus (02f6ff90400d ALSA: hda - Add inverted dmic for Packard Bell DOTS) Merging pci-current/for-linus (99496bd2971f PCI: altera: Fix error when INTx is 4) Merging driver-core.current/driver-core-linus (31ade3b83e18 Linux 4.4-rc3) Merging tty.current/tty-linus (31ade3b83e18 Linux 4.4-rc3) Merging usb.current/usb-linus (4a0c4c36094c USB: host: ohci-at91: fix a crash in ohci_hcd_at91_overcurrent_irq) Merging usb-gadget-fixes/fixes (62e345ae5b6e usb: dwc3: gadget: don't prestart interrupt endpoints) Merging usb-serial-fixes/usb-linus (a0e80fbd56b4 USB: serial: Another Infineon flash loader USB ID) Merging usb-chipidea-fixes/ci-for-usb-stable (6f51bc340d2a usb: chipidea: imx: fix a possible NULL dereference) Merging staging.current/staging-linus (9225c0b7b976 staging: lustre: echo_copy.._lsm() dereferences userland pointers directly) Merging char-misc.current/char-misc-linus (e8c77bda05e5 fpga manager: Fix firmware resource leak on error) Merging input-current/for-linus (1cf44efa1e4f Input: arizona-haptic - fix disabling of haptics device) Merging crypto-current/master (79960943fdc1 crypto: talitos - Fix timing leak in ESP ICV verification) Merging ide/master (1b1050cdc5cd Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide) Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test for PPC
Re: [PATCH 00/12] x86: Rewrite 64-bit syscall code
* Andy Lutomirski wrote: > On Mon, Dec 7, 2015 at 1:51 PM, Andy Lutomirski wrote: > > > This is kind of like the 32-bit and compat code, except that I preserved > > the > > fast path this time. I was unable to measure any significant performance > > change on my laptop in the fast path. > > > > What do you all think? > > For completeness, if I zap the fast path entirely (see attached), I lose 20 > cycles (148 cycles vs 128 cycles) on Skylake. Switching between movq and > pushq > for stack setup makes no difference whatsoever, interestingly. I haven't > tried > to figure out exactly where those 20 cycles go. So I asked for this before, and I'll do so again: could you please stick the cycle granular system call performance test into a 'perf bench' variant so that: 1) More people can run it all on various pieces of hardware and help out quantify the patches. 2) We can keep an eye on not regressing base system call performance in the future, with a good in-tree testcase. 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 v3 0/9] ACPI / LPSS: fix system hangup on BYT/BSW/CHT
On Sat, 5 Dec 2015 01:07:47 +0100 "Rafael J. Wysocki" wrote: > >>> [2] http://www.spinics.net/lists/kernel/msg2119229.html > > I'm the top-level powercap maintainer, but the RAPL driver is > maintained by Jacob. Please ask him for an ACK. looks good to me. no functional change to the driver. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PSEUDOPATCH] rename is_compat_task
* Arnd Bergmann wrote: > On Monday 07 December 2015 15:12:59 Andy Lutomirski wrote: > > Hi all- > > > > Every time I look at is_compat_task, I cringe. That function > > determines whether we're in a compat syscall, not whether we're in a > > compat task. There are probably architectures (arm64?) under which > > these are the same conditions, but they are definitely *not* the same > > thing on x86. > > > > Can we just fix it? I propose the following patch: > > > > $ find -type f |xargs sed -i -e 's/is_compat_task/in_compat_syscall/g' > > > > If there's general agreement, can we do that at the end of the next > > merge window? > > > > I could also send a patch series to add in_compat_syscall, change all > > the users, then delete the old stuff, but that seems overcomplicated > > for something that's literally just renaming a token. > > As far as I know, x86 is the special case here, on all other architectures, > this > actually checks the task, and it's impossible to call a system call of the > other > kind. Well, even on architectures that don't allow mixed mode system calls for the same task the name 'in_compat_syscall()' is still correct: it just happens to also be a permanent condition for the life time of a task. On architectures that allow mixed mode syscalls the assumption and confusion carried by the 'is_compat_task()' misnomer has resulted in real security bugs, hence Andy's suggestion for a rename. So without my x86 hat on I'd still argue that 'is_compat_syscall()' is the more expressive (and hence more robust, safer) name. On architectures that don't care the change carries zero costs. So are there any deep objections to doing this rename in a single, quick, pain-minimized fashion right at the end of the next merge window, when the amount of pending patches in various maintainer trees is at a cyclical minimum? We can also keep an is_compat_task() migratory define for one more cycle just in case. 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/
[tip:perf/core] perf annotate: ARM support
Commit-ID: cfef25b8daf7e4b49c84e174a904af9d89dc7c46
Gitweb: http://git.kernel.org/tip/cfef25b8daf7e4b49c84e174a904af9d89dc7c46
Author: Russell King
AuthorDate: Sun, 6 Dec 2015 23:07:13 +
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 7 Dec 2015 18:13:00 -0300
perf annotate: ARM support
Add basic support to parse ARM assembly.
This:
* enables perf to correctly show the disassembly, rather than chopping
some constants off at the '#' (which is not a comment character on
ARM).
* allows perf to identify ARM instructions that branch to other parts
within the same function, thereby properly annotating them.
* allows perf to identify function calls, allowing called functions to
be followed in the annotated view.
Signed-off-by: Russell King
Cc: Peter Zijlstra
Cc: Will Deacon
Link: http://lkml.kernel.org/n/tip-owp1uj0nmcgfrlppfyeet...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/annotate.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 1dd1949..b795b69 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -65,6 +65,11 @@ static int call__parse(struct ins_operands *ops)
name++;
+#ifdef __arm__
+ if (strchr(name, '+'))
+ return -1;
+#endif
+
tok = strchr(name, '>');
if (tok == NULL)
return -1;
@@ -246,7 +251,11 @@ static int mov__parse(struct ins_operands *ops)
return -1;
target = ++s;
+#ifdef __arm__
+ comment = strchr(s, ';');
+#else
comment = strchr(s, '#');
+#endif
if (comment != NULL)
s = comment - 1;
@@ -354,6 +363,20 @@ static struct ins instructions[] = {
{ .name = "addq", .ops = _ops, },
{ .name = "addw", .ops = _ops, },
{ .name = "and", .ops = _ops, },
+#ifdef __arm__
+ { .name = "b", .ops = _ops, }, // might also be a call
+ { .name = "bcc", .ops = _ops, },
+ { .name = "bcs", .ops = _ops, },
+ { .name = "beq", .ops = _ops, },
+ { .name = "bge", .ops = _ops, },
+ { .name = "bgt", .ops = _ops, },
+ { .name = "bhi", .ops = _ops, },
+ { .name = "bl",.ops = _ops, },
+ { .name = "blt", .ops = _ops, },
+ { .name = "bls", .ops = _ops, },
+ { .name = "blx", .ops = _ops, },
+ { .name = "bne", .ops = _ops, },
+#endif
{ .name = "bts", .ops = _ops, },
{ .name = "call", .ops = _ops, },
{ .name = "callq", .ops = _ops, },
--
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:perf/core] perf stat: Move enable_on_exec setup under earlier code
Commit-ID: c8280cec2a196f2ffea83dd755b17eb020ca1b83
Gitweb: http://git.kernel.org/tip/c8280cec2a196f2ffea83dd755b17eb020ca1b83
Author: Jiri Olsa
AuthorDate: Thu, 3 Dec 2015 10:06:45 +0100
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 7 Dec 2015 18:12:59 -0300
perf stat: Move enable_on_exec setup under earlier code
It's more readable this way and we can save one
perf_evsel__is_group_leader condition in current code.
Signed-off-by: Jiri Olsa
Cc: Adrian Hunter
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1449133606-14429-7-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-stat.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 2e70610..e74712d 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -173,17 +173,20 @@ static int create_perf_stat_counter(struct perf_evsel
*evsel)
* either manually by us or by kernel via enable_on_exec
* set later.
*/
- if (perf_evsel__is_group_leader(evsel))
+ if (perf_evsel__is_group_leader(evsel)) {
attr->disabled = 1;
- if (target__has_cpu())
- return perf_evsel__open_per_cpu(evsel, perf_evsel__cpus(evsel));
-
- if (!target__has_task() && perf_evsel__is_group_leader(evsel)) {
- if (!initial_delay)
+ /*
+* In case of initial_delay we enable tracee
+* events manually.
+*/
+ if (target__none() && !initial_delay)
attr->enable_on_exec = 1;
}
+ if (target__has_cpu())
+ return perf_evsel__open_per_cpu(evsel, perf_evsel__cpus(evsel));
+
return perf_evsel__open_per_thread(evsel, evsel_list->threads);
}
--
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:perf/core] perf evlist: Factor perf_evlist__(enable|disable) functions
Commit-ID: 3e27c92081131738fa4d7dd71673aa6e8c24866d
Gitweb: http://git.kernel.org/tip/3e27c92081131738fa4d7dd71673aa6e8c24866d
Author: Jiri Olsa
AuthorDate: Thu, 3 Dec 2015 10:06:42 +0100
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 7 Dec 2015 18:12:58 -0300
perf evlist: Factor perf_evlist__(enable|disable) functions
Use perf_evsel__(enable|disable) functions in perf_evlist__(enable|disable)
functions in order to centralize ioctl enable/disable calls. This way we
eliminate 2 places calling directly ioctl.
Signed-off-by: Jiri Olsa
Cc: Adrian Hunter
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1449133606-14429-4-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/evlist.c | 32
1 file changed, 8 insertions(+), 24 deletions(-)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index d139219..d1b6c20 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -336,20 +336,12 @@ static int perf_evlist__nr_threads(struct perf_evlist
*evlist,
void perf_evlist__disable(struct perf_evlist *evlist)
{
- int cpu, thread;
struct perf_evsel *pos;
- int nr_cpus = cpu_map__nr(evlist->cpus);
- int nr_threads;
- for (cpu = 0; cpu < nr_cpus; cpu++) {
- evlist__for_each(evlist, pos) {
- if (!perf_evsel__is_group_leader(pos) || !pos->fd)
- continue;
- nr_threads = perf_evlist__nr_threads(evlist, pos);
- for (thread = 0; thread < nr_threads; thread++)
- ioctl(FD(pos, cpu, thread),
- PERF_EVENT_IOC_DISABLE, 0);
- }
+ evlist__for_each(evlist, pos) {
+ if (!perf_evsel__is_group_leader(pos) || !pos->fd)
+ continue;
+ perf_evsel__disable(pos);
}
evlist->enabled = false;
@@ -357,20 +349,12 @@ void perf_evlist__disable(struct perf_evlist *evlist)
void perf_evlist__enable(struct perf_evlist *evlist)
{
- int cpu, thread;
struct perf_evsel *pos;
- int nr_cpus = cpu_map__nr(evlist->cpus);
- int nr_threads;
- for (cpu = 0; cpu < nr_cpus; cpu++) {
- evlist__for_each(evlist, pos) {
- if (!perf_evsel__is_group_leader(pos) || !pos->fd)
- continue;
- nr_threads = perf_evlist__nr_threads(evlist, pos);
- for (thread = 0; thread < nr_threads; thread++)
- ioctl(FD(pos, cpu, thread),
- PERF_EVENT_IOC_ENABLE, 0);
- }
+ evlist__for_each(evlist, pos) {
+ if (!perf_evsel__is_group_leader(pos) || !pos->fd)
+ continue;
+ perf_evsel__enable(pos);
}
evlist->enabled = true;
--
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:perf/core] perf stat: Use perf_evlist__enable in handle_initial_delay
Commit-ID: ab46db0a3325a064bb24e826b12995d157565efb
Gitweb: http://git.kernel.org/tip/ab46db0a3325a064bb24e826b12995d157565efb
Author: Jiri Olsa
AuthorDate: Thu, 3 Dec 2015 10:06:43 +0100
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 7 Dec 2015 18:12:58 -0300
perf stat: Use perf_evlist__enable in handle_initial_delay
No need to mimic the behaviour of perf_evlist__enable, we can use it
directly.
Signed-off-by: Jiri Olsa
Tested-by: Arnaldo Carvalho de Melo
Cc: Adrian Hunter
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1449133606-14429-5-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-stat.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 813c52a..8ca40de 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -253,12 +253,9 @@ static void process_interval(void)
static void handle_initial_delay(void)
{
- struct perf_evsel *counter;
-
if (initial_delay) {
usleep(initial_delay * 1000);
- evlist__for_each(evsel_list, counter)
- perf_evsel__enable(counter);
+ perf_evlist__enable(evsel_list);
}
}
--
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:perf/core] perf stat: Create events as disabled
Commit-ID: 67ccdecd09cac818146b1e153ff901cb67570012
Gitweb: http://git.kernel.org/tip/67ccdecd09cac818146b1e153ff901cb67570012
Author: Jiri Olsa
AuthorDate: Thu, 3 Dec 2015 10:06:44 +0100
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 7 Dec 2015 18:12:59 -0300
perf stat: Create events as disabled
Currently we have 2 kinds of stat counters based on when the event is
enabled:
1) tracee command events, which are enable once the
tracee executes exec syscall (enable_on_exec bit)
2) all other events which get alive within the
perf_event_open syscall
And 2) case could raise a problem in case we want additional filter to
be attached for event. In this case we want the event to be enabled
after it's configured with filter.
Changing the behaviour of 2) events, so they all are created as disabled
(disabled bit). Adding extra enable call to make them alive once they
finish setup.
Signed-off-by: Jiri Olsa
Cc: Adrian Hunter
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1449133606-14429-6-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-stat.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 8ca40de..2e70610 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -168,11 +168,18 @@ static int create_perf_stat_counter(struct perf_evsel
*evsel)
attr->sample_period = 0;
attr->sample_type = 0;
+ /*
+* Disabling all counters initially, they will be enabled
+* either manually by us or by kernel via enable_on_exec
+* set later.
+*/
+ if (perf_evsel__is_group_leader(evsel))
+ attr->disabled = 1;
+
if (target__has_cpu())
return perf_evsel__open_per_cpu(evsel, perf_evsel__cpus(evsel));
if (!target__has_task() && perf_evsel__is_group_leader(evsel)) {
- attr->disabled = 1;
if (!initial_delay)
attr->enable_on_exec = 1;
}
@@ -251,12 +258,18 @@ static void process_interval(void)
print_counters(, 0, NULL);
}
-static void handle_initial_delay(void)
+static void enable_counters(void)
{
- if (initial_delay) {
+ if (initial_delay)
usleep(initial_delay * 1000);
+
+ /*
+* We need to enable counters only if:
+* - we don't have tracee (attaching to task or cpu)
+* - we have initial delay configured
+*/
+ if (!target__none() || initial_delay)
perf_evlist__enable(evsel_list);
- }
}
static volatile int workload_exec_errno;
@@ -353,7 +366,7 @@ static int __run_perf_stat(int argc, const char **argv)
if (forks) {
perf_evlist__start_workload(evsel_list);
- handle_initial_delay();
+ enable_counters();
if (interval) {
while (!waitpid(child_pid, , WNOHANG)) {
@@ -372,7 +385,7 @@ static int __run_perf_stat(int argc, const char **argv)
if (WIFSIGNALED(status))
psignal(WTERMSIG(status), argv[0]);
} else {
- handle_initial_delay();
+ enable_counters();
while (!done) {
nanosleep(, NULL);
if (interval)
--
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:perf/core] perf test: Prevent using bpf-output event in round trip name test
Commit-ID: c0651c41e45dee1d6abb83fd5b25e7097aeac141 Gitweb: http://git.kernel.org/tip/c0651c41e45dee1d6abb83fd5b25e7097aeac141 Author: Jiri Olsa AuthorDate: Thu, 3 Dec 2015 09:34:16 +0100 Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 7 Dec 2015 18:12:56 -0300 perf test: Prevent using bpf-output event in round trip name test The bpf-output is added under software events, but is not parse-able within parse_events, which is what round trip test is expecting. Checking software events only until dummy event. Signed-off-by: Jiri Olsa Acked-by: Namhyung Kim Tested-by: Arnaldo Carvalho de Melo Cc: Adrian Hunter Cc: David Ahern Cc: Masami Hiramatsu Cc: Peter Zijlstra Cc: Wang Nan Link: http://lkml.kernel.org/r/1449131658-1841-6-git-send-email-jo...@kernel.org [ Make it a one liner by keeping __perf_evsel__name_array_test() around ] Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/tests/evsel-roundtrip-name.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/perf/tests/evsel-roundtrip-name.c b/tools/perf/tests/evsel-roundtrip-name.c index 1da92e1..2de4a4f 100644 --- a/tools/perf/tests/evsel-roundtrip-name.c +++ b/tools/perf/tests/evsel-roundtrip-name.c @@ -103,7 +103,8 @@ int test__perf_evsel__roundtrip_name_test(int subtest __maybe_unused) if (err) ret = err; - err = perf_evsel__name_array_test(perf_evsel__sw_names); + err = __perf_evsel__name_array_test(perf_evsel__sw_names, + PERF_COUNT_SW_DUMMY + 1); if (err) ret = err; -- 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:perf/core] perf test: Create kernel maps properly for hist entries test
Commit-ID: d6e94fa6b6dab4668e46665bbe766142af32cc15
Gitweb: http://git.kernel.org/tip/d6e94fa6b6dab4668e46665bbe766142af32cc15
Author: Jiri Olsa
AuthorDate: Wed, 2 Dec 2015 22:08:29 +0100
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 7 Dec 2015 18:12:56 -0300
perf test: Create kernel maps properly for hist entries test
It fixes segfault within machine__exit, that's caused
but not creating kernel maps for machine.. We're calling
machine__destroy_kernel_maps in machine__exit since commit:
ebe9729c8c31 perf machine: Fix to destroy kernel maps when machine exits
Signed-off-by: Jiri Olsa
Acked-by: Namhyung Kim
Tested-by: Arnaldo Carvalho de Melo
Cc: Adrian Hunter
Cc: David Ahern
Cc: Masami Hiramatsu
Cc: Peter Zijlstra
Cc: Wang Nan
Link: http://lkml.kernel.org/r/tip-k4snzv5t4dvdckggzwdzy...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/tests/hists_common.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/tools/perf/tests/hists_common.c b/tools/perf/tests/hists_common.c
index ce80b27..46f453b 100644
--- a/tools/perf/tests/hists_common.c
+++ b/tools/perf/tests/hists_common.c
@@ -87,6 +87,11 @@ struct machine *setup_fake_machine(struct machines *machines)
return NULL;
}
+ if (machine__create_kernel_maps(machine)) {
+ pr_debug("Not enough memory for machine setup\n");
+ goto out;
+ }
+
for (i = 0; i < ARRAY_SIZE(fake_threads); i++) {
struct thread *thread;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/8] spi: lm70llp: remove multiple blank lines
On Mon, Dec 07, 2015 at 08:07:37PM +, Mark Brown wrote: > On Mon, Dec 07, 2015 at 04:17:28PM +0530, Sudip Mukherjee wrote: > > checkpatch complains about multiple blank lines. > > Please don't resubmit already applied patches, please submit against the > latest development code for the subsystem you're submitting to (unless > the change is a bug fix that should go to Linus). I think there is some confusion. I am not seeing v1 of these patches in for-next branch of your spi tree. And in review of v1 you said to use dev_*. And for that last 2 patch of v1 changed and one extra came so I sent the whole series as v2. regards sudip -- 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:perf/core] perf evsel: Use event maps directly in perf_evsel__enable
Commit-ID: 5cd95fc3f8d84a8bb256838fa3b6b59e9095eaa2
Gitweb: http://git.kernel.org/tip/5cd95fc3f8d84a8bb256838fa3b6b59e9095eaa2
Author: Jiri Olsa
AuthorDate: Thu, 3 Dec 2015 10:06:40 +0100
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 7 Dec 2015 18:12:57 -0300
perf evsel: Use event maps directly in perf_evsel__enable
All events now share proper cpu and thread maps. There's no need to pass
those maps from evlist, it's safe to use evsel maps for enabling event.
Signed-off-by: Jiri Olsa
Cc: Adrian Hunter
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1449133606-14429-2-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-stat.c | 5 +
tools/perf/util/evsel.c | 5 -
tools/perf/util/evsel.h | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index df2fbf0..813c52a 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -256,12 +256,9 @@ static void handle_initial_delay(void)
struct perf_evsel *counter;
if (initial_delay) {
- const int ncpus = cpu_map__nr(evsel_list->cpus),
- nthreads = thread_map__nr(evsel_list->threads);
-
usleep(initial_delay * 1000);
evlist__for_each(evsel_list, counter)
- perf_evsel__enable(counter, ncpus, nthreads);
+ perf_evsel__enable(counter);
}
}
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 0a1f4d9..3a9b506 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -981,8 +981,11 @@ int perf_evsel__append_filter(struct perf_evsel *evsel,
return -1;
}
-int perf_evsel__enable(struct perf_evsel *evsel, int ncpus, int nthreads)
+int perf_evsel__enable(struct perf_evsel *evsel)
{
+ int nthreads = thread_map__nr(evsel->threads);
+ int ncpus = cpu_map__nr(evsel->cpus);
+
return perf_evsel__run_ioctl(evsel, ncpus, nthreads,
PERF_EVENT_IOC_ENABLE,
0);
diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
index 0e49bd7..a721592 100644
--- a/tools/perf/util/evsel.h
+++ b/tools/perf/util/evsel.h
@@ -227,7 +227,7 @@ int perf_evsel__append_filter(struct perf_evsel *evsel,
const char *op, const char *filter);
int perf_evsel__apply_filter(struct perf_evsel *evsel, int ncpus, int nthreads,
const char *filter);
-int perf_evsel__enable(struct perf_evsel *evsel, int ncpus, int nthreads);
+int perf_evsel__enable(struct perf_evsel *evsel);
int perf_evsel__open_per_cpu(struct perf_evsel *evsel,
struct cpu_map *cpus);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf evsel: Introduce disable() method
Commit-ID: e98a4cbb01e0ba1110eba5166a425b3eab9b2244
Gitweb: http://git.kernel.org/tip/e98a4cbb01e0ba1110eba5166a425b3eab9b2244
Author: Jiri Olsa
AuthorDate: Thu, 3 Dec 2015 10:06:41 +0100
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 7 Dec 2015 18:12:57 -0300
perf evsel: Introduce disable() method
Adding perf_evsel__disable function to have complement for
perf_evsel__enable function. Both will be used in following patch to
factor perf_evlist__(enable|disable).
Signed-off-by: Jiri Olsa
Cc: Adrian Hunter
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1449133606-14429-3-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/evsel.c | 10 ++
tools/perf/util/evsel.h | 1 +
2 files changed, 11 insertions(+)
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 3a9b506..47f0330 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -991,6 +991,16 @@ int perf_evsel__enable(struct perf_evsel *evsel)
0);
}
+int perf_evsel__disable(struct perf_evsel *evsel)
+{
+ int nthreads = thread_map__nr(evsel->threads);
+ int ncpus = cpu_map__nr(evsel->cpus);
+
+ return perf_evsel__run_ioctl(evsel, ncpus, nthreads,
+PERF_EVENT_IOC_DISABLE,
+0);
+}
+
int perf_evsel__alloc_id(struct perf_evsel *evsel, int ncpus, int nthreads)
{
if (ncpus == 0 || nthreads == 0)
diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
index a721592..5ded1fc 100644
--- a/tools/perf/util/evsel.h
+++ b/tools/perf/util/evsel.h
@@ -228,6 +228,7 @@ int perf_evsel__append_filter(struct perf_evsel *evsel,
int perf_evsel__apply_filter(struct perf_evsel *evsel, int ncpus, int nthreads,
const char *filter);
int perf_evsel__enable(struct perf_evsel *evsel);
+int perf_evsel__disable(struct perf_evsel *evsel);
int perf_evsel__open_per_cpu(struct perf_evsel *evsel,
struct cpu_map *cpus);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf test: Use machine__new_host in mmap thread lookup test
Commit-ID: 046847935754f27c2e8334ff15abda0b733a1fd4
Gitweb: http://git.kernel.org/tip/046847935754f27c2e8334ff15abda0b733a1fd4
Author: Jiri Olsa
AuthorDate: Thu, 3 Dec 2015 09:34:13 +0100
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 7 Dec 2015 18:12:54 -0300
perf test: Use machine__new_host in mmap thread lookup test
This is more straightforward than what we have now.
It also fixes a segfault within machine__exit, that's caused by not
creating kernel maps for machine.. We're calling
machine__destroy_kernel_maps in machine__exit since commit:
ebe9729c8c31 perf machine: Fix to destroy kernel maps when machine exits
Signed-off-by: Jiri Olsa
Acked-by: Namhyung Kim
Tested-by: Arnaldo Carvalho de Melo
Cc: Adrian Hunter
Cc: David Ahern
Cc: Masami Hiramatsu
Cc: Peter Zijlstra
Cc: Wang Nan
Link: http://lkml.kernel.org/r/1449131658-1841-3-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/tests/mmap-thread-lookup.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/tools/perf/tests/mmap-thread-lookup.c
b/tools/perf/tests/mmap-thread-lookup.c
index 6cdb975..0c5ce44 100644
--- a/tools/perf/tests/mmap-thread-lookup.c
+++ b/tools/perf/tests/mmap-thread-lookup.c
@@ -149,7 +149,6 @@ static int synth_process(struct machine *machine)
static int mmap_events(synth_cb synth)
{
- struct machines machines;
struct machine *machine;
int err, i;
@@ -162,8 +161,7 @@ static int mmap_events(synth_cb synth)
*/
TEST_ASSERT_VAL("failed to create threads", !threads_create());
- machines__init();
- machine =
+ machine = machine__new_host();
dump_trace = verbose > 1 ? 1 : 0;
@@ -203,7 +201,7 @@ static int mmap_events(synth_cb synth)
}
machine__delete_threads(machine);
- machines__exit();
+ machine__delete(machine);
return err;
}
--
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:perf/core] perf test: Fix cpus and thread maps reference in error path
Commit-ID: 7320b1b3d9e6af30adcbead64568be3c40b50e59
Gitweb: http://git.kernel.org/tip/7320b1b3d9e6af30adcbead64568be3c40b50e59
Author: Jiri Olsa
AuthorDate: Thu, 3 Dec 2015 09:34:15 +0100
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 7 Dec 2015 18:12:55 -0300
perf test: Fix cpus and thread maps reference in error path
In error path to try user space event, both cpus and threads map now
owned by evlist and freed by perf_evlist__set_maps call. Getting
reference to keep them alive.
Signed-off-by: Jiri Olsa
Acked-by: Namhyung Kim
Cc: Adrian Hunter
Cc: David Ahern
Cc: Masami Hiramatsu
Cc: Peter Zijlstra
Cc: Wang Nan
Link: http://lkml.kernel.org/r/1449131658-1841-5-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/tests/code-reading.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/tools/perf/tests/code-reading.c b/tools/perf/tests/code-reading.c
index 26182ff..313a48c 100644
--- a/tools/perf/tests/code-reading.c
+++ b/tools/perf/tests/code-reading.c
@@ -547,6 +547,13 @@ static int do_test_code_reading(bool try_kcore)
if (ret < 0) {
if (!excl_kernel) {
excl_kernel = true;
+ /*
+* Both cpus and threads are now owned by evlist
+* and will be freed by following
perf_evlist__set_maps
+* call. Getting refference to keep them alive.
+*/
+ cpu_map__get(cpus);
+ thread_map__get(threads);
perf_evlist__set_maps(evlist, NULL, NULL);
perf_evlist__delete(evlist);
evlist = NULL;
--
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:perf/core] perf test: Use machine__new_host in mmap thread code reading test
Commit-ID: 0fd4008ed755c52d85117302a3c2c108b2958420
Gitweb: http://git.kernel.org/tip/0fd4008ed755c52d85117302a3c2c108b2958420
Author: Jiri Olsa
AuthorDate: Thu, 3 Dec 2015 09:34:14 +0100
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 7 Dec 2015 18:12:55 -0300
perf test: Use machine__new_host in mmap thread code reading test
This is more straightforward than what we have now.
It also fixes a segfault within machine__exit, that's caused
by not creating kernel maps for machine.. We're calling
machine__destroy_kernel_maps in machine__exit since commit:
ebe9729c8c31 perf machine: Fix to destroy kernel maps when machine exits
Signed-off-by: Jiri Olsa
Acked-by: Namhyung Kim
Cc: Adrian Hunter
Cc: David Ahern
Cc: Masami Hiramatsu
Cc: Peter Zijlstra
Cc: Wang Nan
Link: http://lkml.kernel.org/r/1449131658-1841-4-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/tests/code-reading.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/tools/perf/tests/code-reading.c b/tools/perf/tests/code-reading.c
index 4417b6a..26182ff 100644
--- a/tools/perf/tests/code-reading.c
+++ b/tools/perf/tests/code-reading.c
@@ -433,7 +433,6 @@ enum {
static int do_test_code_reading(bool try_kcore)
{
- struct machines machines;
struct machine *machine;
struct thread *thread;
struct record_opts opts = {
@@ -459,8 +458,7 @@ static int do_test_code_reading(bool try_kcore)
pid = getpid();
- machines__init();
- machine =
+ machine = machine__new_host();
ret = machine__create_kernel_maps(machine);
if (ret < 0) {
@@ -594,9 +592,8 @@ out_err:
cpu_map__put(cpus);
thread_map__put(threads);
}
- machines__destroy_kernel_maps();
machine__delete_threads(machine);
- machines__exit();
+ machine__delete(machine);
return err;
}
--
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:perf/core] perf test: Use machine__new_host in dwarf unwind test
Commit-ID: bdaba8aee5c3806d78ee4f130048b2238c636d47
Gitweb: http://git.kernel.org/tip/bdaba8aee5c3806d78ee4f130048b2238c636d47
Author: Jiri Olsa
AuthorDate: Thu, 3 Dec 2015 09:34:12 +0100
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 7 Dec 2015 18:12:54 -0300
perf test: Use machine__new_host in dwarf unwind test
This is more straightforward than what we have now.
It also fixes a segfault within machine__exit, that's caused by not
creating kernel maps for machine.. We're calling
machine__destroy_kernel_maps in machine__exit since commit:
ebe9729c8c31 perf machine: Fix to destroy kernel maps when machine exits
Signed-off-by: Jiri Olsa
Acked-by: Namhyung Kim
Cc: Adrian Hunter
Cc: David Ahern
Cc: Masami Hiramatsu
Cc: Peter Zijlstra
Cc: Wang Nan
Link: http://lkml.kernel.org/r/1449131658-1841-2-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/tests/dwarf-unwind.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/tools/perf/tests/dwarf-unwind.c b/tools/perf/tests/dwarf-unwind.c
index 3cce13b1..1c5c022 100644
--- a/tools/perf/tests/dwarf-unwind.c
+++ b/tools/perf/tests/dwarf-unwind.c
@@ -160,14 +160,11 @@ static int krava_1(struct thread *thread)
int test__dwarf_unwind(int subtest __maybe_unused)
{
- struct machines machines;
struct machine *machine;
struct thread *thread;
int err = -1;
- machines__init();
-
- machine = machines__find(, HOST_KERNEL_ID);
+ machine = machine__new_host();
if (!machine) {
pr_err("Could not get machine\n");
return -1;
@@ -199,7 +196,6 @@ int test__dwarf_unwind(int subtest __maybe_unused)
out:
machine__delete_threads(machine);
- machine__exit(machine);
- machines__exit();
+ machine__delete(machine);
return err;
}
--
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/
undefined reference to `dib3000mc_pid_parse'
Hi Kirill, It's probably a bug fix that unveils the link errors. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 62ea1ec5e17fe36e2c728bc534f9f78b216dfe83 commit: 51b97e354ba9fce1890cf38ecc754aa49677fc89 kernel: use the gnu89 standard explicitly date: 1 year, 1 month ago config: x86_64-randconfig-a0-12081135 (attached as .config) reproduce: git checkout 51b97e354ba9fce1890cf38ecc754aa49677fc89 # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): drivers/built-in.o: In function `dibusb_dib3000mc_frontend_attach': >> (.text+0x207627): undefined reference to `dib3000mc_pid_parse' drivers/built-in.o: In function `dibusb_dib3000mc_frontend_attach': >> (.text+0x20762f): undefined reference to `dib3000mc_pid_control' drivers/built-in.o: In function `dibusb_dib3000mc_tuner_attach': (.text+0x20773a): undefined reference to `dib3000mc_get_tuner_i2c_master' drivers/built-in.o: In function `dibusb_dib3000mc_tuner_attach': >> (.text+0x207822): undefined reference to `dib3000mc_set_config' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
[tip:perf/core] perf machine: Pass correct string to dso__adjust_kmod_long_name
Commit-ID: 5dcf16df3ce48b2e4f798b1a11b5de2fc3cfd73a
Gitweb: http://git.kernel.org/tip/5dcf16df3ce48b2e4f798b1a11b5de2fc3cfd73a
Author: Wang Nan
AuthorDate: Mon, 7 Dec 2015 02:36:25 +
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 7 Dec 2015 18:12:45 -0300
perf machine: Pass correct string to dso__adjust_kmod_long_name
There's a mistake in dso__adjust_kmod_long_name() that it use strdup()
to dup the new long_name of a dso, but passes the original string to
dso__set_long_name(). Which causes random crash during cleanup.
Signed-off-by: Wang Nan
Reviewed-by: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Zefan Li
Cc: pi3or...@163.com
Fixes: c03d5184f0e9 ("perf machine: Adjust dso->long_name for offline module")
Link:
http://lkml.kernel.org/r/1449455785-42020-1-git-send-email-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/machine.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 95a7f60..bfc289c 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -576,7 +576,7 @@ static void dso__adjust_kmod_long_name(struct dso *dso,
const char *filename)
if (!dup_filename)
return;
- dso__set_long_name(dso, filename, true);
+ dso__set_long_name(dso, dup_filename, true);
}
struct map *machine__findnew_module_map(struct machine *machine, u64 start,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 04/14] perf: Move term functions out of util.c
The term functions are needed by help.c which is going to be moved into
a separate library. Move them out of util.c and into their own file.
Signed-off-by: Josh Poimboeuf
---
tools/perf/util/Build | 1 +
tools/perf/util/term.c | 35 +++
tools/perf/util/term.h | 7 +++
tools/perf/util/util.c | 34 --
tools/perf/util/util.h | 4 +---
5 files changed, 44 insertions(+), 37 deletions(-)
create mode 100644 tools/perf/util/term.c
create mode 100644 tools/perf/util/term.h
diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index 0513dd5..6c3bbd5 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -87,6 +87,7 @@ libperf-$(CONFIG_AUXTRACE) += intel-pt.o
libperf-$(CONFIG_AUXTRACE) += intel-bts.o
libperf-y += parse-branch-options.o
libperf-y += parse-regs-options.o
+libperf-y += term.o
libperf-$(CONFIG_LIBBPF) += bpf-loader.o
libperf-$(CONFIG_BPF_PROLOGUE) += bpf-prologue.o
diff --git a/tools/perf/util/term.c b/tools/perf/util/term.c
new file mode 100644
index 000..90b47d8
--- /dev/null
+++ b/tools/perf/util/term.c
@@ -0,0 +1,35 @@
+#include "util.h"
+
+void get_term_dimensions(struct winsize *ws)
+{
+ char *s = getenv("LINES");
+
+ if (s != NULL) {
+ ws->ws_row = atoi(s);
+ s = getenv("COLUMNS");
+ if (s != NULL) {
+ ws->ws_col = atoi(s);
+ if (ws->ws_row && ws->ws_col)
+ return;
+ }
+ }
+#ifdef TIOCGWINSZ
+ if (ioctl(1, TIOCGWINSZ, ws) == 0 &&
+ ws->ws_row && ws->ws_col)
+ return;
+#endif
+ ws->ws_row = 25;
+ ws->ws_col = 80;
+}
+
+void set_term_quiet_input(struct termios *old)
+{
+ struct termios tc;
+
+ tcgetattr(0, old);
+ tc = *old;
+ tc.c_lflag &= ~(ICANON | ECHO);
+ tc.c_cc[VMIN] = 0;
+ tc.c_cc[VTIME] = 0;
+ tcsetattr(0, TCSANOW, );
+}
diff --git a/tools/perf/util/term.h b/tools/perf/util/term.h
new file mode 100644
index 000..7b13f46
--- /dev/null
+++ b/tools/perf/util/term.h
@@ -0,0 +1,7 @@
+#ifndef __PERF_TERM_H
+#define __PERF_TERM_H
+
+void get_term_dimensions(struct winsize *ws);
+void set_term_quiet_input(struct termios *old);
+
+#endif /* __PERF_TERM_H */
diff --git a/tools/perf/util/util.c b/tools/perf/util/util.c
index 75759ae..07da970 100644
--- a/tools/perf/util/util.c
+++ b/tools/perf/util/util.c
@@ -355,40 +355,6 @@ void sighandler_dump_stack(int sig)
exit(sig);
}
-void get_term_dimensions(struct winsize *ws)
-{
- char *s = getenv("LINES");
-
- if (s != NULL) {
- ws->ws_row = atoi(s);
- s = getenv("COLUMNS");
- if (s != NULL) {
- ws->ws_col = atoi(s);
- if (ws->ws_row && ws->ws_col)
- return;
- }
- }
-#ifdef TIOCGWINSZ
- if (ioctl(1, TIOCGWINSZ, ws) == 0 &&
- ws->ws_row && ws->ws_col)
- return;
-#endif
- ws->ws_row = 25;
- ws->ws_col = 80;
-}
-
-void set_term_quiet_input(struct termios *old)
-{
- struct termios tc;
-
- tcgetattr(0, old);
- tc = *old;
- tc.c_lflag &= ~(ICANON | ECHO);
- tc.c_cc[VMIN] = 0;
- tc.c_cc[VTIME] = 0;
- tcsetattr(0, TCSANOW, );
-}
-
int parse_nsec_time(const char *str, u64 *ptime)
{
u64 time_sec, time_nsec;
diff --git a/tools/perf/util/util.h b/tools/perf/util/util.h
index cd0d9b0..d8e3d8d 100644
--- a/tools/perf/util/util.h
+++ b/tools/perf/util/util.h
@@ -9,6 +9,7 @@
#include "srcline.h"
#include "strbuf.h"
#include "string.h"
+#include "term.h"
#include "usage.h"
#include "wrapper.h"
#include "zlib.h"
@@ -38,9 +39,6 @@ void sighandler_dump_stack(int sig);
extern unsigned int page_size;
extern int cacheline_size;
-void get_term_dimensions(struct winsize *ws);
-void set_term_quiet_input(struct termios *old);
-
struct parse_tag {
char tag;
int mult;
--
2.4.3
--
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/
