Re: [PATCH RFC net-next 08/14] bpf: add eBPF verifier
On Tue, Jul 1, 2014 at 10:05 PM, Namhyung Kim wrote:
> Mostly questions and few nitpicks.. :)
great questions. Thank you for review! Answers below:
> On Fri, 27 Jun 2014 17:06:00 -0700, Alexei Starovoitov wrote:
>> +/* types of values:
>> + * - stored in an eBPF register
>> + * - passed into helper functions as an argument
>> + * - returned from helper functions
>> + */
>> +enum bpf_reg_type {
>> + INVALID_PTR,/* reg doesn't contain a valid pointer
>> */
>
> I don't think it's a good name. The INVALID_PTR can be read as it
> contains a "pointer" which is invalid. Maybe INTEGER, NUMBER or
> something different can be used. And I think the struct reg_state->ptr
> should be renamed also.
ok. I agree that 'invalid' part of the name is too negative.
May be 'unknown_value' ?
>> + PTR_TO_CTX, /* reg points to bpf_context */
>> + PTR_TO_MAP, /* reg points to map element value */
>> + PTR_TO_MAP_CONDITIONAL, /* points to map element value or NULL
>> */
>> + PTR_TO_STACK, /* reg == frame_pointer */
>> + PTR_TO_STACK_IMM, /* reg == frame_pointer + imm */
>> + PTR_TO_STACK_IMM_MAP_KEY, /* pointer to stack used as map key */
>> + PTR_TO_STACK_IMM_MAP_VALUE, /* pointer to stack used as map elem */
>
> So, these PTR_TO_STACK_IMM[_*] types are only for function argument,
> right? I guessed it could be used to access memory in general too, but
> then I thought it'd make verification complicated..
>
> And I also agree that it'd better splitting reg types and function
> argument constraints.
Ok. Will split this enum into three.
>> +
>> +/* check read/write into map element returned by bpf_table_lookup() */
>> +static int check_table_access(struct verifier_env *env, int regno, int off,
>> + int size)
>
> I guess the "table" is an old name of the "map"?
oops :) Yes. I've been calling them 'bpf tables' initially, but it created too
strong of a correlation to 'hash table', so I've changed the name to 'map'
to stress that this is a generic key/value and not just hash table.
>> + } else if (state->regs[regno].ptr == PTR_TO_STACK) {
>> + if (off >= 0 || off < -MAX_BPF_STACK) {
>> + verbose("invalid stack off=%d size=%d\n", off, size);
>> + return -EACCES;
>> + }
>
> So memory (stack) access is only allowed for a stack base regsiter and a
> constant offset, right?
Correct.
In other words it allows instructions:
BPF_STX_MEM(BPF_W, BPF_REG_10, BPF_REG_xx, -stack_offset);
Verifier makes no attempt to track pointer arithmetic and just marks
the result as 'invalid_ptr'.
For non-root programs it will reject programs that are trying to do
arithmetic on pointers (it's not part of this patch yet).
>> + /* check args */
>> + _(check_func_arg(env, BPF_REG_1, fn->arg1_type, _id, ));
>> + _(check_func_arg(env, BPF_REG_2, fn->arg2_type, _id, ));
>> + _(check_func_arg(env, BPF_REG_3, fn->arg3_type, _id, ));
>> + _(check_func_arg(env, BPF_REG_4, fn->arg4_type, _id, ));
>
> Missing BPF_REG_5?
yes. good catch.
I guess this shows that we didn't have a use case for function with 5 args :)
Will fix this.
>> +#define PEAK_INT() \
>
> s/PEAK/PEEK/ ?
aren't these the same? ;))
Will fix. Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/14] cpufreq: cpu0: defer probe if clock isn't registered yet
On 2 July 2014 11:23, Shawn Guo wrote:
> On Tue, Jul 01, 2014 at 10:02:35PM +0530, Viresh Kumar wrote:
>> diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
>> index 4273a5f..b5b8e1c 100644
>> --- a/drivers/cpufreq/cpufreq-cpu0.c
>> +++ b/drivers/cpufreq/cpufreq-cpu0.c
>> @@ -150,8 +150,17 @@ static int cpu0_cpufreq_probe(struct platform_device
>> *pdev)
>>
>> cpu_clk = clk_get(cpu_dev, NULL);
>> if (IS_ERR(cpu_clk)) {
>> - ret = PTR_ERR(cpu_clk);
>
> If you keep this ...
>
>> - pr_err("failed to get cpu0 clock: %d\n", ret);
>> + /*
>> + * If cpu's clk node is present, but clock is not yet
>> + * registered, we should try defering probe.
>> + */
>> + if (PTR_ERR(cpu_clk) == -EPROBE_DEFER) {
>
> ... you can use 'ret' here ...
>
>> + dev_err(cpu_dev, "cpu0 clock not ready, retry\n");
>> + ret = -EPROBE_DEFER;
>
> ... this can be saved ...
>
>> + } else {
>> + ret = PTR_ERR(cpu_clk);
>
> ... and this as well.
All accepted. Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] f2fs: check bdi->dirty_exceeded when trying to skip data writes
On Sat, 28 Jun 2014 20:58:38 +0900 Jaegeuk Kim wrote:
> If we don't check the current backing device status, balance_dirty_pages can
> fall into infinite pausing routine.
>
> This can be occurred when a lot of directories make a small number of dirty
> dentry pages including files.
>
> ...
>
> --- a/fs/f2fs/node.c
> +++ b/fs/f2fs/node.c
> @@ -43,6 +43,8 @@ bool available_free_memory(struct f2fs_sb_info *sbi, int
> type)
> mem_size = (nm_i->nat_cnt * sizeof(struct nat_entry)) >> 12;
> res = mem_size < ((val.totalram * nm_i->ram_thresh / 100) >> 2);
> } else if (type == DIRTY_DENTS) {
> + if (sbi->sb->s_bdi->dirty_exceeded)
> + return false;
> mem_size = get_pages(sbi, F2FS_DIRTY_DENTS);
> res = mem_size < ((val.totalram * nm_i->ram_thresh / 100) >> 1);
> }
err, filesystems should not be playing around with this.
Perhaps VFS changes are needed. Please tell us much much more about
what is going on here.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] CMA page migration failure due to buffers on bh_lru
On Mon, 30 Jun 2014 19:02:45 -0700 Laura Abbott wrote: > On 6/30/2014 6:07 PM, Gioh Kim wrote: > > Hi,Laura. > > > > I have a question. > > > > Does the __evict_bh_lru() not need bh_lru_lock()? > > The get_cpu_var() has already preenpt_disable() and can prevent other > > thread. > > But get_cpu_var cannot prevent IRQ context such like page-fault. > > I think if a page-fault occured and a file is read in IRQ context it can > > change cpu-lru. > > > > Is my concern correct? > > > > > > __evict_bh_lru is called via on_each_cpu_cond which I believe will disable > irqs. > I based the code on the existing invalidate_bh_lru which did not take the > bh_lru_lock > either. It's possible I missed something though. I fear that running on_each_cpu() within try_to_free_buffers() is going to be horridly expensive in some cases. Maybe CMA can use invalidate_bh_lrus() to shoot down everything before trying the allocation attempt. That should increase the success rate greatly and doesn't burden page reclaim. The bh LRU isn't terribly important from a performance point of view, so emptying it occasionally won't hurt. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] arm64: eBPF JIT compiler
On Tue, Jul 1, 2014 at 10:20 PM, Zi Shen Lim wrote:
> The JIT compiler emits A64 instructions. It supports eBPF only.
> Legacy BPF is supported thanks to conversion by BPF core.
>
> JIT is enabled in the same way as for other architectures:
>
> echo 1 > /proc/sys/net/core/bpf_jit_enable
>
> Or for additional compiler output:
>
> echo 2 > /proc/sys/net/core/bpf_jit_enable
>
> See Documentation/networking/filter.txt for more information.
>
> The implementation passes all 57 tests in lib/test_bpf.c
> on ARMv8 Foundation Model :)
>
> Signed-off-by: Zi Shen Lim
Wow. This is awesome!
Haven't studied the patch in detail yet…
> NOTES:
>
> * This patch applies on top of current net-next @ 763e0ecd72fe
> ("bonding: allow to add vlans on top of empty bond").
>
> * bpf_jit_comp.c is checkpatch clean.
>
> * Checkpatch warns about long lines for bpf_jit.h, but those
> lines are actually more readable as is.
>
> * The following sparse warning is not applicable:
> warning: symbol 'bpf_jit_enable' was not declared. Should it be static?
>
> PENDING:
>
> 1. Implement remaining classes of eBPF instructions: ST|MEM, STX|XADD
>which currently do not have corresponding test cases in test_bpf.
>
> 2. Move out of arch/arm64/net/, when appropriate, in line with BPF
>infra split.
>
> 3. Further compiler optimization is possible and can be targetted
>for phase 2 implementation.
> ---
> Documentation/networking/filter.txt | 2 +-
> arch/arm64/Kconfig | 1 +
> arch/arm64/Makefile | 1 +
> arch/arm64/net/Makefile | 4 +
> arch/arm64/net/bpf_jit.h| 315
> arch/arm64/net/bpf_jit_comp.c | 698
>
> 6 files changed, 1020 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm64/net/Makefile
> create mode 100644 arch/arm64/net/bpf_jit.h
> create mode 100644 arch/arm64/net/bpf_jit_comp.c
>
> diff --git a/Documentation/networking/filter.txt
> b/Documentation/networking/filter.txt
> index ee78eba..d71e616 100644
> --- a/Documentation/networking/filter.txt
> +++ b/Documentation/networking/filter.txt
> @@ -462,7 +462,7 @@ JIT compiler
>
>
> The Linux kernel has a built-in BPF JIT compiler for x86_64, SPARC, PowerPC,
> -ARM and s390 and can be enabled through CONFIG_BPF_JIT. The JIT compiler is
> +ARM, ARM64 and s390 and can be enabled through CONFIG_BPF_JIT. The JIT
> compiler is
> transparently invoked for each attached filter from user space or for
> internal
> kernel users if it has been previously enabled by root:
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index a474de34..b0a4ff8 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -32,6 +32,7 @@ config ARM64
> select HAVE_ARCH_KGDB
> select HAVE_ARCH_TRACEHOOK
> select HAVE_C_RECORDMCOUNT
> + select HAVE_BPF_JIT
> select HAVE_DEBUG_BUGVERBOSE
> select HAVE_DEBUG_KMEMLEAK
> select HAVE_DMA_API_DEBUG
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index 8185a91..0cd6b9c 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -43,6 +43,7 @@ TEXT_OFFSET := 0x0008
> export TEXT_OFFSET GZFLAGS
>
> core-y += arch/arm64/kernel/ arch/arm64/mm/
> +core-y += arch/arm64/net/
> core-$(CONFIG_KVM) += arch/arm64/kvm/
> core-$(CONFIG_XEN) += arch/arm64/xen/
> core-$(CONFIG_CRYPTO) += arch/arm64/crypto/
> diff --git a/arch/arm64/net/Makefile b/arch/arm64/net/Makefile
> new file mode 100644
> index 000..da97633
> --- /dev/null
> +++ b/arch/arm64/net/Makefile
> @@ -0,0 +1,4 @@
> +#
> +# ARM64 networking code
> +#
> +obj-$(CONFIG_BPF_JIT) += bpf_jit_comp.o
> diff --git a/arch/arm64/net/bpf_jit.h b/arch/arm64/net/bpf_jit.h
> new file mode 100644
> index 000..5013969
> --- /dev/null
> +++ b/arch/arm64/net/bpf_jit.h
> @@ -0,0 +1,315 @@
> +/*
> + * BPF JIT compiler for ARM64
> + *
> + * Copyright (C) 2014 Zi Shen Lim
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see
Re: [PATCH v2 0/9] Updated fence patch series
On Tue, Jul 01, 2014 at 12:57:02PM +0200, Maarten Lankhorst wrote: > So after some more hacking I've moved dma-buf to its own subdirectory, > drivers/dma-buf and applied the fence patches to its new place. I believe > that the > first patch should be applied regardless, and the rest should be ready now. > :-) > > Changes to the fence api: > - release_fence -> fence_release etc. > - __fence_init -> fence_init > - __fence_signal -> fence_signal_locked > - __fence_is_signaled -> fence_is_signaled_locked > - Changing BUG_ON to WARN_ON in fence_later, and return NULL if it triggers. > > Android can expose fences to userspace. It's possible to make the new fence > mechanism expose the same fences to userspace by changing sync_fence_create > to take a struct fence instead of a struct sync_pt. No other change is needed, > because only the fence parts of struct sync_pt are used. But because the > userspace fences are a separate problem and I haven't really looked at it yet > I feel it should stay in staging, for now. Ok, that's reasonable. At first glance, this all looks "sane" to me, any objection from anyone if I merge this through my driver-core tree for 3.17? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC net-next 01/14] net: filter: split filter.c into two files
On Tue, Jul 1, 2014 at 9:23 PM, Namhyung Kim wrote: > Hi Alexei, > > On Fri, 27 Jun 2014 17:05:53 -0700, Alexei Starovoitov wrote: >> BPF is used in several kernel components. This split creates logical boundary >> between generic eBPF core and the rest >> >> kernel/bpf/core.c: eBPF interpreter >> >> net/core/filter.c: classic->eBPF converter, classic verifiers, socket filters >> >> This patch only moves functions. >> >> Signed-off-by: Alexei Starovoitov >> --- >> kernel/Makefile |1 + >> kernel/bpf/Makefile |1 + >> kernel/bpf/core.c | 545 >> +++ >> net/core/filter.c | 520 >> 4 files changed, 547 insertions(+), 520 deletions(-) >> create mode 100644 kernel/bpf/Makefile >> create mode 100644 kernel/bpf/core.c >> >> diff --git a/kernel/Makefile b/kernel/Makefile >> index f2a8b6246ce9..e7360b7c2c0e 100644 >> --- a/kernel/Makefile >> +++ b/kernel/Makefile >> @@ -87,6 +87,7 @@ obj-$(CONFIG_RING_BUFFER) += trace/ >> obj-$(CONFIG_TRACEPOINTS) += trace/ >> obj-$(CONFIG_IRQ_WORK) += irq_work.o >> obj-$(CONFIG_CPU_PM) += cpu_pm.o >> +obj-$(CONFIG_NET) += bpf/ > > But this still requires CONFIG_NET to use bpf. Why not adding > CONFIG_BPF and making CONFIG_NET selects it? This is the first patch that does 'split only'. Later patch replaces this line with CONFIG_BPF. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] arm: mach-omap2: gpmc: ignore non-available nodes
>From: Ezequiel García [mailto:ezequ...@vanguardiasur.com.ar] >>On 26 Jun 12:02 PM, Guido Martínez wrote: >> Currently, child nodes of the gpmc node are iterated and probed >> regardless of their 'status' property. This means adding 'status = >> "disabled";' has no effect. >> >> This patch changes the iteration to only probe nodes marked as >> available. >> >> Signed-off-by: Guido Martínez > >Just a nit: the commit title doesn't match the recent commits. If you >run "git log" on this file, you'll find the pattern should be something >like: > >"ARM: OMAP2+: GPMC should only probe enabled devices" > >Other than this, the patch looks correct. > Yes, plz keep patch title consistent as in other gpmc.c patches. And thanks for this fix. Tested-by: Pekon Gupta with regards, pekon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC net-next 03/14] bpf: introduce syscall(BPF, ...) and BPF maps
On Tue, Jul 1, 2014 at 8:11 AM, Andy Lutomirski wrote: > On Mon, Jun 30, 2014 at 10:47 PM, Alexei Starovoitov > wrote: >> On Mon, Jun 30, 2014 at 3:09 PM, Andy Lutomirski wrote: >>> On Sat, Jun 28, 2014 at 11:36 PM, Alexei Starovoitov >>> wrote: On Sat, Jun 28, 2014 at 6:52 PM, Andy Lutomirski wrote: > On Sat, Jun 28, 2014 at 1:49 PM, Alexei Starovoitov > wrote: >> >> Sorry I don't like 'fd' direction at all. >> 1. it will make the whole thing very socket specific and 'net' dependent. >> but the goal here is to be able to use eBPF for tracing in embedded >> setups. So it's gotta be net independent. >> 2. sockets are already overloaded with all sorts of stuff. Adding more >> types of sockets will complicate it a lot. >> 3. and most important. read/write operations on sockets are not >> done every nanosecond, whereas lookup operations on bpf maps >> are done every dozen instructions, so we cannot have any overhead >> when accessing maps. >> In other words the verifier is done as static analyzer. I moved all >> the complexity to verify time, so at run-time the programs are as >> fast as possible. I'm strongly against run-time checks in critical path, >> since they kill performance and make the whole approach a lot less >> usable. > > I may have described my suggestion poorly. I'm suggesting that all of > these global ids be replaced *for userspace's benefit* with fds. That > is, a map would have an associated struct inode, and, when you load an > eBPF program, you'd pass fds into the kernel instead of global ids. > The kernel would still compile the eBPF program to use the global ids, > though. Hmm. If I understood you correctly, you're suggesting to do it similar to ipc/mqueue, shmem, sockets do. By registering and mounting a file system and providing all superblock and inode hooks… and probably have its own namespace type… hmm… may be. That's quite a bit of work to put lightly. As I said in the other email the first step is root only and all these complexity just not worth doing at this stage. >>> >>> The downside of not doing it right away is that it's harder to >>> retrofit in without breaking early users. >>> >>> You might be able to get away with using anon_inodes. That will >> >> Spent quite a bit of time playing with anon_inode_getfd(). The model >> works ok for seccomp, but doesn't seem to work for tracing, >> since tracepoints are global. Say, syscall(bpf, load_prog) returns >> a process-local fd. This 'fd' as a string can be written to >> debugfs/tracing/events/.../filter which will increment a refcnt of a global >> ebpf_program structure and will keep using it. When process exits it will >> close all fds which in case of ebpf_prog_fd should be a nop, since >> the program is still attached to a global event. Now we have a >> program and maps that still alive and dangling, since tracepoint events >> keep coming, but no new process can access it. Here we just lost all >> benefits of making it 'fd' based. Theoretically we can extend tracing to >> be fd-based too and tracepoints will auto-detach upon process exit, >> but that's not going to work for all other global events. Like networking >> components (bridge, ovs, …) are global and they won't be adding >> fd-based interfaces. >> I'm still thinking about it, but it looks like that any process-local >> ebpf_prog_id scheme is not going to work for global events. Thoughts? > > Hmm. Maybe these things do need global ids for tracing, or at least > there need to be some way to stash them somewhere and find them again. > I suppose that debugfs could have symlinks to them, but I don't know > how hard that would be to implement or how awkward it would be to use. > > I imagine there's some awkwardness regardless. For tracing, if I > create map 75 and eBPF program 492 that uses map 75, then I still need > to remember that map 75 is the map I want (or I need to parse the eBPF > program later on). > > How do you imagine the userspace code working? Maybe it would make > sense to add some nlattrs for eBPF programs to map between referenced > objects and nicknames for them. Then user code could look at > /sys/kernel/debug/whatever/nickname_of_map to resolve the map id or > even just open it directly. I want to avoid string names, since they will force new 'strtab', 'symtab' sections in the programs/maps and will uglify the user interface quite a bit. Back in september one loadable unit was: one eBPF program + set of maps, but tracing requirements forced a change, since multiple programs need to access the same map and maps may need to be pre-populated before the programs start executing, so I've split maps and programs into mostly independent entities, but programs still need to think of maps as local: For example I want to do a skb leak check 'tracing filter': - attach this program to kretprobe of
[PATCH] block: fix reqeust->__data_len overflow
blk_rq_sectors(req) + bio_sectors(bio) > blk_rq_get_max_sectors(req)
is used to check whether a bio can be merged into an exist request.
If can, req->__data_len += bio->bio_size. Since req->__data_len is
a 32bit uint, if blk_rq_get_max_sectors(req) > (UINT_MAX >> 9),
req->__date_len may overflow when merging a new bio.
This probably happen for discard request. In xen blkfront driver,
its max_discard_sectors is set to the whole disk sector size, see
xlvbd_init_blk_queue(). So issuing discrad requests to a
xen virtual disk with a size over 4G is very possible to trigger the
overflow. This overflow will cause kernel panic in blk_end_request_all()
due to BUG() triggered.
The following is a call trace we saw in 3.0.69. Upstream kernel also suffer
this issue.
@ __end_that: dev xvdg: type=1, flags=2224441
@ sector 0, nr/cnr 8378368/4294959104
@ bio 8803d8cf3080, biotail 8803d8cf32c0, buffer (null),
@ len 4289724416
@ blk_update_request: bio idx 0 >= vcnt 0
@ request botched: dev xvdg: type=1, flags=2224441
@ sector 0, nr/cnr 8378368/4294959104
@ bio 8803d8cf3080, biotail 8803d8cf32c0, buffer (null),
@ len 4289724416
@ [ cut here ]
@ kernel BUG at block/blk-core.c:2394!
@ invalid opcode: [#1] SMP
@ CPU 0
@ Modules linked in: nfs fscache auth_rpcgss nfs_acl autofs4 i2c_dev i2c_core
@ lockd sunrpc(U) ksplice_x773z34q_vmlinux_new(U) ksplice_x773z34q(U)
@ ksplice_bj7y22gc_vmlinux_new(U) ksplice_bj7y22gc_ipv6_new(U)
@ ksplice_bj7y22gc(U)
@ .
@ ksplice_i1o46065(U) ksplice_5gqtkuvt_vmlinux_new(U) ksplice_5gqtkuvt(U)
@ ksplice_2bcv8td6(U) ksplice_v5bs54bz_vmlinux_new(U) ksplice_v5bs54bz(U)
@ ksplice_l7s0dhx6(U) ksplice_aur7sgvi(U) ksplice_ckie4cpv(U)
@ nf_conntrack_netbios_ns
@ .
@ nf_conntrack_broadcast ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 xt_state
@ nf_conntrack xt_comment iptable_filter ip_tables be2iscsi iscsi_boot_sysfs
@ ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp bnx2i cnic
@ uio ipv6
@ .
@ cxgb3i libcxgbi cxgb3 mdio libiscsi_tcp libiscsi scsi_transport_iscsi
@ parport_pc lp parport snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq
@ snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore
@ snd_page_alloc
@ .
@ pcspkr xen_netfront dm_snapshot dm_zero dm_mirror dm_region_hash dm_log
@ dm_mod xen_blkfront ext3 jbd mbcache sd_mod crc_t10dif [last unloaded:
@ ksplice_x773z34q_vmlinux_old]
@ .
@ Pid: 0, comm: swapper Not tainted 2.6.39-400.212.1.el5uek #1
@ RIP: e030:[] []
@ __blk_end_request_all+0x2a/0x40
@ RSP: e02b:8803ffc03df8 EFLAGS: 00010002
@ RAX: 0001 RBX: 8803db3c8000 RCX: 8803d8cf32c0
@ RDX: 0001 RSI: 8803d8cf3080 RDI: 8803daed08d8
@ RBP: 8803ffc03df8 R08: R09: 8803daed08d8
@ R10: R11: 000a R12:
@ R13: 8803dad5e3c0 R14: 0001 R15: 0029
@ FS: 7f1f34a32940() GS:8803ffc0() knlGS:
@ CS: e033 DS: ES: CR0: 8005003b
@ CR2: 020c6148 CR3: 0003c6492000 CR4: 2660
@ DR0: DR1: DR2:
@ DR3: DR6: 0ff0 DR7: 0400
@ Process swapper (pid: 0, threadinfo 81794000, task 8179f020)
@ Stack:
@ 8803ffc03e48 a005c56a 8803da57a8d0 0028810d99ee
@ 8803db1ea7c0 8803db1beec0 005e
@ 0001 8803ffc03e98 810d735d
@ Call Trace:
@
@ [] blkif_interrupt+0x20a/0x3a0 [xen_blkfront]
@ [] handle_irq_event_percpu+0x5d/0x1a0
@ [] handle_irq_event+0x4f/0x80
@ [] handle_edge_irq+0xa5/0x100
@ [] __xen_evtchn_do_upcall+0x218/0x310
@ [] xen_evtchn_do_upcall+0x2f/0x50
@ [] xen_do_hypervisor_callback+0x1e/0x30
@
@ [] ? xen_hypercall_sched_op+0xa/0x20
@ [] ? xen_hypercall_sched_op+0xa/0x20
@ [] ? xen_safe_halt+0x10/0x20
@ [] ? default_idle+0x5b/0x170
@ [] ? cpu_idle+0xc6/0xf0
@ [] ? rest_init+0x72/0x80
@ [] ? start_kernel+0x2aa/0x390
@ [] ? x86_64_start_reservations+0x6a/0xa0
@ [] ? xen_start_kernel+0x315/0x440
@ Code: 00 55 48 89 e5 0f 1f 44 00 00 48 8b 87 60 01 00 00 31 c9 48 85 c0 75 0e
@ 8b 57 54 e8 91 ff ff ff 84 c0 75 07 c9 c3 8b 48 54 eb ed <0f> 0b 0f 1f 40 00
@ eb fa 0f 1f 80 00 00 00 00 0f 1f 80 00 00 00
@ RIP [] __blk_end_request_all+0x2a/0x40
@ RSP
@ ---[ end trace b09ff97496363201 ]---
Signed-off-by: Junxiao Bi
---
block/blk-merge.c | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/block/blk-merge.c b/block/blk-merge.c
index b3bf0df..ae4f4c8 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -325,11 +325,30 @@ no_merge:
return 0;
}
-int ll_back_merge_fn(struct request_queue *q, struct request *req,
+static inline bool ll_allow_merge_bio(struct request *req,
struct bio *bio)
{
if
Re: [PATCH RFC net-next 11/14] tracing: allow eBPF programs to be attached to events
On Fri, 27 Jun 2014 17:06:03 -0700, Alexei Starovoitov wrote:
> User interface:
> cat bpf_123 > /sys/kernel/debug/tracing/__event__/filter
>
> where 123 is an id of the eBPF program priorly loaded.
> __event__ is static tracepoint event.
> (kprobe events will be supported in the future patches)
>
> eBPF programs can call in-kernel helper functions to:
> - lookup/update/delete elements in maps
> - memcmp
> - trace_printk
ISTR Steve doesn't like to use trace_printk() (at least for production
kernels) anymore. And I'm not sure it'd work if there's no existing
trace_printk() on a system.
> - load_pointer
> - dump_stack
[SNIP]
> @@ -634,6 +635,15 @@ ftrace_raw_event_##call(void *__data, proto)
> \
> if (ftrace_trigger_soft_disabled(ftrace_file)) \
> return; \
> \
> + if (unlikely(ftrace_file->flags & FTRACE_EVENT_FL_FILTERED) && \
> + unlikely(ftrace_file->event_call->flags & TRACE_EVENT_FL_BPF)) { \
> + struct bpf_context __ctx; \
> + \
> + populate_bpf_context(&__ctx, args, 0, 0, 0, 0, 0); \
> + trace_filter_call_bpf(ftrace_file->filter, &__ctx); \
> + return; \
> + } \
> + \
Hmm.. But it seems the eBPF prog is not a filter - it'd always drop the
event. And I think it's better to use a recorded entry rather then args
as a bpf_context so that tools like perf can manipulate it at compile
time based on the event format.
Thanks,
Namhyung
> __data_size = ftrace_get_offsets_##call(&__data_offsets, args); \
> \
> entry = ftrace_event_buffer_reserve(, ftrace_file, \
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/1] firmware: read firmware size using i_size_read()
On Wed, Jul 02, 2014 at 09:33:49AM +0800, Ming Lei wrote: > On Thu, Jun 26, 2014 at 12:46 AM, Dmitry Kasatkin > wrote: > > On 13 June 2014 19:06, Dmitry Kasatkin wrote: > >> On 13 June 2014 19:03, Ming Lei wrote: > >>> On Fri, Jun 13, 2014 at 11:09 PM, Dmitry Kasatkin > >>> wrote: > There is no need to read attr because inode structure contains size > of the file. Use i_size_read() instead. > > Signed-off-by: Dmitry Kasatkin > >>> > >>> Acked-by: Ming Lei > >>> > > > > > > Hi, > > > > BTW. To what tree it is applied? > > Greg will take it in driver-core tree. Yes, I'll catch up on pending patches next week, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[f2fs-dev][PATCH 2/2] f2fs: introduce f2fs_write_failed to handle error case when write
When we fail in ->write_begin()/->direct_IO(), our allocated node block in disk
and page cache are still kept, despite these may not be used again.
This patch introduce f2fs_write_failed() to handle the error case of these two
interfaces, it will truncate page cache and blocks of this file according to
i_size.
Signed-off-by: Chao Yu
---
fs/f2fs/data.c | 42 +++---
1 file changed, 31 insertions(+), 11 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 2eb2764..05154d6 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -914,6 +914,16 @@ skip_write:
return 0;
}
+static void f2fs_write_failed(struct address_space *mapping, loff_t to)
+{
+ struct inode *inode = mapping->host;
+
+ if (to > inode->i_size) {
+ truncate_pagecache(inode, inode->i_size);
+ truncate_blocks(inode, inode->i_size);
+ }
+}
+
static int f2fs_write_begin(struct file *file, struct address_space *mapping,
loff_t pos, unsigned len, unsigned flags,
struct page **pagep, void **fsdata)
@@ -931,11 +941,13 @@ static int f2fs_write_begin(struct file *file, struct
address_space *mapping,
repeat:
err = f2fs_convert_inline_data(inode, pos + len);
if (err)
- return err;
+ goto fail;
page = grab_cache_page_write_begin(mapping, index, flags);
- if (!page)
- return -ENOMEM;
+ if (!page) {
+ err = -ENOMEM;
+ goto fail;
+ }
/* to avoid latency during memory pressure */
unlock_page(page);
@@ -949,10 +961,9 @@ repeat:
set_new_dnode(, inode, NULL, NULL, 0);
err = f2fs_reserve_block(, index);
f2fs_unlock_op(sbi);
-
if (err) {
f2fs_put_page(page, 0);
- return err;
+ goto fail;
}
inline_data:
lock_page(page);
@@ -982,19 +993,20 @@ inline_data:
err = f2fs_read_inline_data(inode, page);
if (err) {
page_cache_release(page);
- return err;
+ goto fail;
}
} else {
err = f2fs_submit_page_bio(sbi, page, dn.data_blkaddr,
READ_SYNC);
if (err)
- return err;
+ goto fail;
}
lock_page(page);
if (unlikely(!PageUptodate(page))) {
f2fs_put_page(page, 1);
- return -EIO;
+ err = -EIO;
+ goto fail;
}
if (unlikely(page->mapping != mapping)) {
f2fs_put_page(page, 1);
@@ -1005,6 +1017,9 @@ out:
SetPageUptodate(page);
clear_cold_data(page);
return 0;
+fail:
+ f2fs_write_failed(mapping, pos + len);
+ return err;
}
static int f2fs_write_end(struct file *file,
@@ -1049,7 +1064,10 @@ static ssize_t f2fs_direct_IO(int rw, struct kiocb *iocb,
struct iov_iter *iter, loff_t offset)
{
struct file *file = iocb->ki_filp;
- struct inode *inode = file->f_mapping->host;
+ struct address_space *mapping = file->f_mapping;
+ struct inode *inode = mapping->host;
+ size_t count = iov_iter_count(iter);
+ int err;
/* Let buffer I/O handle the inline data case. */
if (f2fs_has_inline_data(inode))
@@ -1061,8 +1079,10 @@ static ssize_t f2fs_direct_IO(int rw, struct kiocb *iocb,
/* clear fsync mark to recover these blocks */
fsync_mark_clear(F2FS_SB(inode->i_sb), inode->i_ino);
- return blockdev_direct_IO(rw, iocb, inode, iter, offset,
- get_data_block);
+ err = blockdev_direct_IO(rw, iocb, inode, iter, offset, get_data_block);
+ if (err < 0 && (rw & WRITE))
+ f2fs_write_failed(mapping, offset + count);
+ return err;
}
static void f2fs_invalidate_data_page(struct page *page, unsigned int offset,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[f2fs-dev][PATCH 1/2] f2fs: check name_len of dir entry to prevent from deadloop
We assume that modification of some special application could result in zeroed
name_len, or it is consciously made by somebody. We will deadloop in
find_in_block when name_len of dir entry is zero.
This patch is added for preventing deadloop in above scenario.
Signed-off-by: Chao Yu
---
fs/f2fs/dir.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index be8c7af..4316ec5 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -121,6 +121,16 @@ static struct f2fs_dir_entry *find_in_block(struct page
*dentry_page,
}
}
+ /* check name_len to prevent from deadloop here */
+ if (unlikely(de->name_len == 0)) {
+ struct inode *inode = dentry_page->mapping->host;
+
+ f2fs_msg(inode->i_sb, KERN_ERR,
+ "zero-length dir entry, ino = %lu, name = %s",
+ (unsigned long)inode->i_ino, name->name);
+ break;
+ }
+
bit_start = bit_pos
+ GET_DENTRY_SLOTS(le16_to_cpu(de->name_len));
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC] arm64: eBPF JIT compiler
The JIT compiler emits A64 instructions. It supports eBPF only.
Legacy BPF is supported thanks to conversion by BPF core.
JIT is enabled in the same way as for other architectures:
echo 1 > /proc/sys/net/core/bpf_jit_enable
Or for additional compiler output:
echo 2 > /proc/sys/net/core/bpf_jit_enable
See Documentation/networking/filter.txt for more information.
The implementation passes all 57 tests in lib/test_bpf.c
on ARMv8 Foundation Model :)
Signed-off-by: Zi Shen Lim
NOTES:
* This patch applies on top of current net-next @ 763e0ecd72fe
("bonding: allow to add vlans on top of empty bond").
* bpf_jit_comp.c is checkpatch clean.
* Checkpatch warns about long lines for bpf_jit.h, but those
lines are actually more readable as is.
* The following sparse warning is not applicable:
warning: symbol 'bpf_jit_enable' was not declared. Should it be static?
PENDING:
1. Implement remaining classes of eBPF instructions: ST|MEM, STX|XADD
which currently do not have corresponding test cases in test_bpf.
2. Move out of arch/arm64/net/, when appropriate, in line with BPF
infra split.
3. Further compiler optimization is possible and can be targetted
for phase 2 implementation.
---
Documentation/networking/filter.txt | 2 +-
arch/arm64/Kconfig | 1 +
arch/arm64/Makefile | 1 +
arch/arm64/net/Makefile | 4 +
arch/arm64/net/bpf_jit.h| 315
arch/arm64/net/bpf_jit_comp.c | 698
6 files changed, 1020 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/net/Makefile
create mode 100644 arch/arm64/net/bpf_jit.h
create mode 100644 arch/arm64/net/bpf_jit_comp.c
diff --git a/Documentation/networking/filter.txt
b/Documentation/networking/filter.txt
index ee78eba..d71e616 100644
--- a/Documentation/networking/filter.txt
+++ b/Documentation/networking/filter.txt
@@ -462,7 +462,7 @@ JIT compiler
The Linux kernel has a built-in BPF JIT compiler for x86_64, SPARC, PowerPC,
-ARM and s390 and can be enabled through CONFIG_BPF_JIT. The JIT compiler is
+ARM, ARM64 and s390 and can be enabled through CONFIG_BPF_JIT. The JIT
compiler is
transparently invoked for each attached filter from user space or for internal
kernel users if it has been previously enabled by root:
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index a474de34..b0a4ff8 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -32,6 +32,7 @@ config ARM64
select HAVE_ARCH_KGDB
select HAVE_ARCH_TRACEHOOK
select HAVE_C_RECORDMCOUNT
+ select HAVE_BPF_JIT
select HAVE_DEBUG_BUGVERBOSE
select HAVE_DEBUG_KMEMLEAK
select HAVE_DMA_API_DEBUG
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 8185a91..0cd6b9c 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -43,6 +43,7 @@ TEXT_OFFSET := 0x0008
export TEXT_OFFSET GZFLAGS
core-y += arch/arm64/kernel/ arch/arm64/mm/
+core-y += arch/arm64/net/
core-$(CONFIG_KVM) += arch/arm64/kvm/
core-$(CONFIG_XEN) += arch/arm64/xen/
core-$(CONFIG_CRYPTO) += arch/arm64/crypto/
diff --git a/arch/arm64/net/Makefile b/arch/arm64/net/Makefile
new file mode 100644
index 000..da97633
--- /dev/null
+++ b/arch/arm64/net/Makefile
@@ -0,0 +1,4 @@
+#
+# ARM64 networking code
+#
+obj-$(CONFIG_BPF_JIT) += bpf_jit_comp.o
diff --git a/arch/arm64/net/bpf_jit.h b/arch/arm64/net/bpf_jit.h
new file mode 100644
index 000..5013969
--- /dev/null
+++ b/arch/arm64/net/bpf_jit.h
@@ -0,0 +1,315 @@
+/*
+ * BPF JIT compiler for ARM64
+ *
+ * Copyright (C) 2014 Zi Shen Lim
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see
Re: [PATCH 2/2] MIPS: Alchemy: common clock framework integration
Quoting Manuel Lauss (2014-06-29 09:57:35) > Expose chip-internal configurable clocks to the common clk framework, > and fix a few drivers to take advantage of it. Thanks for the patch series! Both patches cover a lot of ground, but I'll focus on #2. It would be best to split the driver changes out separately. You can introduce the common clk changes but not compile them in, then change the drivers, then add the logic to compile the new common clock driver all as separate patches. > diff --git a/arch/mips/alchemy/common/Makefile > b/arch/mips/alchemy/common/Makefile > index cb83d8d..2e4d505 100644 > --- a/arch/mips/alchemy/common/Makefile > +++ b/arch/mips/alchemy/common/Makefile > @@ -5,7 +5,7 @@ > # Makefile for the Alchemy Au1xx0 CPUs, generic files. > # > > -obj-y += prom.o time.o clocks.o platform.o power.o setup.o \ > +obj-y += prom.o time.o clock.o platform.o power.o setup.o \ > sleeper.o dma.o dbdma.o vss.o irq.o usb.o As stated above, in the first patch only introduce arch/mips/alchemy/common/clock, but don't compile it here in the Makefile. A quick glance through clock.c below looks pretty good. I'll go through it in more detail once the other parts of the series are split out. Additionally, it would be cool to push this driver out to drivers/clk/ if you are so inclined. It looks like your header dependencies are not so bad as to make that task impossible. Just a suggestion from me. Regards, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: qmi_wwan: Add ID for Telewell TW-LTE 4G v2
On 2014-07-02 02:01, Bernd Wachter wrote:
There's a new version of the Telewell 4G modem working with, but not
recognized by this driver.
Signed-off-by: Bernd Wachter
---
--- linux-3.15.3/drivers/net/usb/qmi_wwan.c.orig2014-07-01
21:31:07.0 +0300
+++ linux-3.15.3/drivers/net/usb/qmi_wwan.c 2014-07-01 20:39:30.0
+0300
@@ -741,6 +741,7 @@ static const struct usb_device_id produc
{QMI_FIXED_INTF(0x19d2, 0x1424, 2)},
{QMI_FIXED_INTF(0x19d2, 0x1425, 2)},
{QMI_FIXED_INTF(0x19d2, 0x1426, 2)},/* ZTE MF91 */
+ {QMI_FIXED_INTF(0x19d2, 0x1428, 2)},/* Telewell TW-LTE 4G v2 */
{QMI_FIXED_INTF(0x19d2, 0x2002, 4)},/* ZTE (Vodafone) K3765-Z */
{QMI_FIXED_INTF(0x0f3d, 0x68a2, 8)},/* Sierra Wireless MC7700 */
{QMI_FIXED_INTF(0x114f, 0x68a2, 8)},/* Sierra Wireless MC7750 */
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
For completeness (full device support) please create a patch for the
serial interfaces in the option driver, see the entry for ZTE pid 1426
in option.c as example.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/6] regulator: palmas: cleanup and fixes
On Monday 30 June 2014 09:27 PM, Nishanth Menon wrote: Hi, Original thread (v1): http://marc.info/?t=14038076654=1=2 This series is based on: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git branch: topic/palmas (4c0c9ca Merge remote-tracking branch 'regulator/fix/palmas' into regulator-palmas) This series does a few cleanups to help ensure we dont make typo mistakes and finally provides a fix as attempted by (v1). Basic cpufreq tests performed on OMAP5uEVM, DRA7-evm, DRA72-evm all of which are palmas variants. The patches are also available here: https://github.com/nmenon/linux-2.6-playground/commits/broonie-topic-palmas-fixes For the series: Acked-by: Keerthy Nishanth Menon (6): regulator: palmas: Squelch sparse warnings regulator: palmas: Rename reg_info to palmas_reg_info regulator: palmas: Simplify code by using pointer to palmas_reg_info regulator: palmas: Rename palmas_regs_info to palmas_generic_regs_info regulator: palmas: Simplify code by not indexing regulator_desc unnecessarily regulator: palmas: Fix SMPS enable/disable/is_enable for tps65917 drivers/regulator/palmas-regulator.c | 344 -- include/linux/mfd/palmas.h |4 +- 2 files changed, 166 insertions(+), 182 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1] [SCSI] bfa: use ARRAY_SIZE instead of sizeof/sizeof[0]
Acked-by: Anil Gurumurthy
-Original Message-
From: Fabian Frederick [mailto:f...@skynet.be]
Sent: 30 June 2014 23:13
To: linux-kernel
Cc: Fabian Frederick; Anil Gurumurthy; Sudarsana Kalluru; James E.J. Bottomley;
linux-scsi
Subject: [PATCH 1/1] [SCSI] bfa: use ARRAY_SIZE instead of sizeof/sizeof[0]
Use macro definition
Cc: Anil Gurumurthy
Cc: Sudarsana Kalluru
Cc: "James E.J. Bottomley"
Cc: linux-s...@vger.kernel.org
Signed-off-by: Fabian Frederick
---
drivers/scsi/bfa/bfa_fcs.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/bfa/bfa_fcs.c b/drivers/scsi/bfa/bfa_fcs.c index
a3ab5cc..0f19455 100644
--- a/drivers/scsi/bfa/bfa_fcs.c
+++ b/drivers/scsi/bfa/bfa_fcs.c
@@ -81,7 +81,7 @@ bfa_fcs_attach(struct bfa_fcs_s *fcs, struct bfa_s *bfa,
struct bfad_s *bfad,
bfa->fcs = BFA_TRUE;
fcbuild_init();
- for (i = 0; i < sizeof(fcs_modules) / sizeof(fcs_modules[0]); i++) {
+ for (i = 0; i < ARRAY_SIZE(fcs_modules); i++) {
mod = _modules[i];
if (mod->attach)
mod->attach(fcs);
@@ -97,7 +97,7 @@ bfa_fcs_init(struct bfa_fcs_s *fcs)
int i;
struct bfa_fcs_mod_s *mod;
- for (i = 0; i < sizeof(fcs_modules) / sizeof(fcs_modules[0]); i++) {
+ for (i = 0; i < ARRAY_SIZE(fcs_modules); i++) {
mod = _modules[i];
if (mod->modinit)
mod->modinit(fcs);
@@ -184,7 +184,7 @@ bfa_fcs_exit(struct bfa_fcs_s *fcs)
bfa_wc_init(>wc, bfa_fcs_exit_comp, fcs);
- nmods = sizeof(fcs_modules) / sizeof(fcs_modules[0]);
+ nmods = ARRAY_SIZE(fcs_modules);
for (i = 0; i < nmods; i++) {
--
1.8.4.5
This message and any attached documents contain information from QLogic
Corporation or its wholly-owned subsidiaries that may be confidential. If you
are not the intended recipient, you may not read, copy, distribute, or use this
information. If you have received this transmission in error, please notify the
sender immediately by reply e-mail and then delete this message.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the scsi tree with the tree
Hi James,
Today's linux-next merge of the scsi tree got a conflict in
include/scsi/sg.h between commit d15156138dad ("block SG_IO: add
SG_FLAG_Q_AT_HEAD flag") from the block tree and commit b15b9fab9f32
("sg: add SG_FLAG_Q_AT_TAIL flag") from the scsi tree.
I fixed it up (I used the version from the block tree) and can carry the
fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: [PATCH RFC net-next 08/14] bpf: add eBPF verifier
Mostly questions and few nitpicks.. :)
On Fri, 27 Jun 2014 17:06:00 -0700, Alexei Starovoitov wrote:
> +/* types of values:
> + * - stored in an eBPF register
> + * - passed into helper functions as an argument
> + * - returned from helper functions
> + */
> +enum bpf_reg_type {
> + INVALID_PTR,/* reg doesn't contain a valid pointer
> */
I don't think it's a good name. The INVALID_PTR can be read as it
contains a "pointer" which is invalid. Maybe INTEGER, NUMBER or
something different can be used. And I think the struct reg_state->ptr
should be renamed also.
> + PTR_TO_CTX, /* reg points to bpf_context */
> + PTR_TO_MAP, /* reg points to map element value */
> + PTR_TO_MAP_CONDITIONAL, /* points to map element value or NULL
> */
> + PTR_TO_STACK, /* reg == frame_pointer */
> + PTR_TO_STACK_IMM, /* reg == frame_pointer + imm */
> + PTR_TO_STACK_IMM_MAP_KEY, /* pointer to stack used as map key */
> + PTR_TO_STACK_IMM_MAP_VALUE, /* pointer to stack used as map elem */
So, these PTR_TO_STACK_IMM[_*] types are only for function argument,
right? I guessed it could be used to access memory in general too, but
then I thought it'd make verification complicated..
And I also agree that it'd better splitting reg types and function
argument constraints.
> + RET_INTEGER,/* function returns integer */
> + RET_VOID, /* function returns void */
> + CONST_ARG, /* function expects integer constant
> argument */
> + CONST_ARG_MAP_ID, /* int const argument that is used as
> map_id */
That means a map id should always be a constant (for verification), right?
> + /* int const argument indicating number of bytes accessed from stack
> + * previous function argument must be ptr_to_stack_imm
> + */
> + CONST_ARG_STACK_IMM_SIZE,
> +};
[SNIP]
> +
> +/* check read/write into map element returned by bpf_table_lookup() */
> +static int check_table_access(struct verifier_env *env, int regno, int off,
> + int size)
I guess the "table" is an old name of the "map"?
> +{
> + struct bpf_map *map;
> + int map_id = env->cur_state.regs[regno].imm;
> +
> + _(get_map_info(env, map_id, ));
> +
> + if (off < 0 || off + size > map->value_size) {
> + verbose("invalid access to map_id=%d leaf_size=%d off=%d
> size=%d\n",
> + map_id, map->value_size, off, size);
> + return -EACCES;
> + }
> + return 0;
> +}
[SNIP]
> +static int check_mem_access(struct verifier_env *env, int regno, int off,
> + int bpf_size, enum bpf_access_type t,
> + int value_regno)
> +{
> + struct verifier_state *state = >cur_state;
> + int size;
> +
> + _(size = bpf_size_to_bytes(bpf_size));
> +
> + if (off % size != 0) {
> + verbose("misaligned access off %d size %d\n", off, size);
> + return -EACCES;
> + }
> +
> + if (state->regs[regno].ptr == PTR_TO_MAP) {
> + _(check_table_access(env, regno, off, size));
> + if (t == BPF_READ)
> + mark_reg_no_ptr(state->regs, value_regno);
> + } else if (state->regs[regno].ptr == PTR_TO_CTX) {
> + _(check_ctx_access(env, off, size, t));
> + if (t == BPF_READ)
> + mark_reg_no_ptr(state->regs, value_regno);
> + } else if (state->regs[regno].ptr == PTR_TO_STACK) {
> + if (off >= 0 || off < -MAX_BPF_STACK) {
> + verbose("invalid stack off=%d size=%d\n", off, size);
> + return -EACCES;
> + }
So memory (stack) access is only allowed for a stack base regsiter and a
constant offset, right?
> + if (t == BPF_WRITE)
> + _(check_stack_write(state, off, size, value_regno));
> + else
> + _(check_stack_read(state, off, size, value_regno));
> + } else {
> + verbose("R%d invalid mem access '%s'\n",
> + regno, reg_type_str[state->regs[regno].ptr]);
> + return -EACCES;
> + }
> + return 0;
> +}
[SNIP]
> +static int check_call(struct verifier_env *env, int func_id)
> +{
> + struct verifier_state *state = >cur_state;
> + const struct bpf_func_proto *fn = NULL;
> + struct reg_state *regs = state->regs;
> + struct bpf_map *map = NULL;
> + struct reg_state *reg;
> + int map_id = -1;
> + int i;
> +
> + /* find function prototype */
> + if (func_id <= 0 || func_id >= __BPF_FUNC_MAX_ID) {
> + verbose("invalid func %d\n", func_id);
> + return -EINVAL;
> + }
> +
> + if (env->prog->info->ops->get_func_proto)
> + fn =
Re: [PATCH v2] clk: s2mps11: Fix double free corruption during driver unbind
Quoting Krzysztof Kozlowski (2014-06-27 05:21:10)
> After unbinding the driver memory was corrupted by double free of
> clk_lookup structure. This lead to OOPS when re-binding the driver
> again.
>
> The driver allocated memory for 'clk_lookup' with devm_kzalloc. During
> driver removal this memory was freed twice: once by clkdev_drop() and
> second by devm code.
Applied to clk-fixes.
Thanks,
Mike
>
> Kernel panic log:
> [ 30.839284] Unable to handle kernel paging request at virtual address
> 5f343173
> [ 30.846476] pgd = dee14000
> [ 30.849165] [5f343173] *pgd=
> [ 30.852703] Internal error: Oops: 805 [#1] PREEMPT SMP ARM
> [ 30.858166] Modules linked in:
> [ 30.861208] CPU: 0 PID: 1 Comm: bash Not tainted
> 3.16.0-rc2-00239-g94bdf617b07e-dirty #40
> [ 30.869364] task: df478000 ti: df48 task.ti: df48
> [ 30.874752] PC is at clkdev_add+0x2c/0x38
> [ 30.878738] LR is at clkdev_add+0x18/0x38
> [ 30.882732] pc : []lr : []psr: 6013
> [ 30.882732] sp : df481e78 ip : 0001 fp : c0700ed8
> [ 30.894187] r10: 000c r9 : r8 : c07b0e3c
> [ 30.899396] r7 : 0002 r6 : df45f9d0 r5 : df421390 r4 : c0700d6c
> [ 30.905906] r3 : 5f343173 r2 : c0700d84 r1 : 6013 r0 : c0700d6c
> [ 30.912417] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment
> user
> [ 30.919534] Control: 10c53c7d Table: 5ee1406a DAC: 0015
> [ 30.925262] Process bash (pid: 1, stack limit = 0xdf480240)
> [ 30.930817] Stack: (0xdf481e78 to 0xdf482000)
> [ 30.935159] 1e60:
> 1000 df6de610
> [ 30.943321] 1e80: df7f4558 c0355650 c05ec6ec c0700eb0 df6de600 df7f4510
> dec9d69c 0014
> [ 30.951480] 1ea0: 00167b48 df6de610 c0700e30 c0713518 c0700e30
> dec9d69c 0006
> [ 30.959639] 1ec0: 00167b48 c02c1b7c c02c1b64 df6de610 c07aff48 c02c0420
> c06fb150 c047cc20
> [ 30.967798] 1ee0: df6de610 df6de610 c0700e30 df6de644 c06fb150 000c
> dec9d690 c02bef90
> [ 30.975957] 1f00: dec9c6c0 dece4c00 df481f80 dece4c00 000c c02be73c
> 000c c016ca8c
> [ 30.984116] 1f20: c016ca48 c016c1f4
> b6f18000 df481f80
> [ 30.992276] 1f40: df7f66c0 000c df48 df48 b6f18000 c011094c
> df47839c 6013
> [ 31.000435] 1f60: df7f66c0 df7f66c0 000c df48
> b6f18000 c0110dd4
> [ 31.008594] 1f80: 000c b6ec05d8 000c b6f18000
> 0004 c000f2a8
> [ 31.016753] 1fa0: 1000 c000f0e0 b6ec05d8 000c 0001 b6f18000
> 000c
> [ 31.024912] 1fc0: b6ec05d8 000c b6f18000 0004 000c 0001
> 00167b48
> [ 31.033071] 1fe0: bed83a80 b6e004f0 b6e5122c 6010 0001
>
> [ 31.041248] [] (clkdev_add) from []
> (s2mps11_clk_probe+0x2b4/0x3b4)
> [ 31.049223] [] (s2mps11_clk_probe) from []
> (platform_drv_probe+0x18/0x48)
> [ 31.057728] [] (platform_drv_probe) from []
> (driver_probe_device+0x13c/0x384)
> [ 31.066579] [] (driver_probe_device) from []
> (bind_store+0x88/0xd8)
> [ 31.074564] [] (bind_store) from []
> (drv_attr_store+0x20/0x2c)
> [ 31.082118] [] (drv_attr_store) from []
> (sysfs_kf_write+0x44/0x48)
> [ 31.090016] [] (sysfs_kf_write) from []
> (kernfs_fop_write+0xc0/0x17c)
> [ 31.098176] [] (kernfs_fop_write) from []
> (vfs_write+0xa0/0x1c4)
> [ 31.105899] [] (vfs_write) from []
> (SyS_write+0x40/0x8c)
> [ 31.112931] [] (SyS_write) from []
> (ret_fast_syscall+0x0/0x3c)
> [ 31.120481] Code: e2842018 e584501c e1a4 e885000c (e5835000)
> [ 31.126596] ---[ end trace efad45bfa3a61b05 ]---
> [ 31.131181] Kernel panic - not syncing: Fatal exception
> [ 31.136368] CPU1: stopping
> [ 31.139054] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D
> 3.16.0-rc2-00239-g94bdf617b07e-dirty #40
> [ 31.148697] [] (unwind_backtrace) from []
> (show_stack+0x10/0x14)
> [ 31.156419] [] (show_stack) from []
> (dump_stack+0x80/0xcc)
> [ 31.163622] [] (dump_stack) from []
> (handle_IPI+0x130/0x15c)
> [ 31.170998] [] (handle_IPI) from []
> (gic_handle_irq+0x60/0x68)
> [ 31.178549] [] (gic_handle_irq) from []
> (__irq_svc+0x40/0x70)
> [ 31.186009] Exception stack(0xdf4bdf88 to 0xdf4bdfd0)
> [ 31.191046] df80: ffed
> df4bc000 c06d042c
> [ 31.199207] dfa0: ffed c06d03c0 c070c288
> df4bdfd0
> [ 31.207363] dfc0: c0010324 c0010328 6013
> [ 31.212402] [] (__irq_svc) from []
> (arch_cpu_idle+0x28/0x30)
> [ 31.219783] [] (arch_cpu_idle) from []
> (cpu_startup_entry+0x2c4/0x3f0)
> [ 31.228027] [] (cpu_startup_entry) from [<400086c4>] (0x400086c4)
> [ 31.234968] ---[ end Kernel panic - not syncing: Fatal exception
>
> Fixes: 7cc560dea415 ("clk: s2mps11: Add support for s2mps11")
> Cc:
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> Changes since v1:
>
[PATCH 1/1] ice1712: Aligning definitions in header file
Aligning #defines in ice1712.h file. Signed-off-by: Konstantinos Tsimpoukas --- sound/pci/ice1712/ice1712.h | 84 ++--- 1 file changed, 42 insertions(+), 42 deletions(-) diff --git a/sound/pci/ice1712/ice1712.h b/sound/pci/ice1712/ice1712.h index b209fc3..f88800a 100644 --- a/sound/pci/ice1712/ice1712.h +++ b/sound/pci/ice1712/ice1712.h @@ -41,18 +41,18 @@ #define ICEREG(ice, x) ((ice)->port + ICE1712_REG_##x) #define ICE1712_REG_CONTROL0x00/* byte */ -#define ICE1712_RESET0x80/* reset whole chip */ -#define ICE1712_SERR_LEVEL 0x04/* SERR# level otherwise edge */ -#define ICE1712_NATIVE 0x01/* native mode otherwise SB */ +#define ICE1712_RESET 0x80/* reset whole chip */ +#define ICE1712_SERR_LEVEL 0x04/* SERR# level otherwise edge */ +#define ICE1712_NATIVE 0x01/* native mode otherwise SB */ #define ICE1712_REG_IRQMASK0x01/* byte */ -#define ICE1712_IRQ_MPU1 0x80 -#define ICE1712_IRQ_TIMER0x40 -#define ICE1712_IRQ_MPU2 0x20 -#define ICE1712_IRQ_PROPCM 0x10 -#define ICE1712_IRQ_FM 0x08/* FM/MIDI - legacy */ -#define ICE1712_IRQ_PBKDS0x04/* playback DS channels */ -#define ICE1712_IRQ_CONCAP 0x02/* consumer capture */ -#define ICE1712_IRQ_CONPBK 0x01/* consumer playback */ +#define ICE1712_IRQ_MPU1 0x80 +#define ICE1712_IRQ_TIMER 0x40 +#define ICE1712_IRQ_MPU2 0x20 +#define ICE1712_IRQ_PROPCM 0x10 +#define ICE1712_IRQ_FM 0x08/* FM/MIDI - legacy */ +#define ICE1712_IRQ_PBKDS 0x04/* playback DS channels */ +#define ICE1712_IRQ_CONCAP 0x02/* consumer capture */ +#define ICE1712_IRQ_CONPBK 0x01/* consumer playback */ #define ICE1712_REG_IRQSTAT0x02/* byte */ /* look to ICE1712_IRQ_* */ #define ICE1712_REG_INDEX 0x03/* byte - indirect CCIxx regs */ @@ -62,23 +62,23 @@ #define ICE1712_REG_NMI_INDEX 0x07/* byte */ #define ICE1712_REG_AC97_INDEX 0x08/* byte */ #define ICE1712_REG_AC97_CMD 0x09/* byte */ -#define ICE1712_AC97_COLD0x80/* cold reset */ -#define ICE1712_AC97_WARM0x40/* warm reset */ -#define ICE1712_AC97_WRITE 0x20/* W: write, R: write in progress */ -#define ICE1712_AC97_READ0x10/* W: read, R: read in progress */ -#define ICE1712_AC97_READY 0x08/* codec ready status bit */ -#define ICE1712_AC97_PBK_VSR 0x02/* playback VSR */ -#define ICE1712_AC97_CAP_VSR 0x01/* capture VSR */ +#define ICE1712_AC97_COLD 0x80/* cold reset */ +#define ICE1712_AC97_WARM 0x40/* warm reset */ +#define ICE1712_AC97_WRITE 0x20/* W: write, R: write in progress */ +#define ICE1712_AC97_READ 0x10/* W: read, R: read in progress */ +#define ICE1712_AC97_READY 0x08/* codec ready status bit */ +#define ICE1712_AC97_PBK_VSR 0x02/* playback VSR */ +#define ICE1712_AC97_CAP_VSR 0x01/* capture VSR */ #define ICE1712_REG_AC97_DATA 0x0a/* word (little endian) */ #define ICE1712_REG_MPU1_CTRL 0x0c/* byte */ #define ICE1712_REG_MPU1_DATA 0x0d/* byte */ #define ICE1712_REG_I2C_DEV_ADDR 0x10/* byte */ -#define ICE1712_I2C_WRITE0x01/* write direction */ +#define ICE1712_I2C_WRITE 0x01/* write direction */ #define ICE1712_REG_I2C_BYTE_ADDR 0x11/* byte */ #define ICE1712_REG_I2C_DATA 0x12/* byte */ #define ICE1712_REG_I2C_CTRL 0x13/* byte */ -#define ICE1712_I2C_EEPROM 0x80/* EEPROM exists */ -#define ICE1712_I2C_BUSY 0x01/* busy bit */ +#define ICE1712_I2C_EEPROM 0x80/* EEPROM exists */ +#define ICE1712_I2C_BUSY 0x01/* busy bit */ #define ICE1712_REG_CONCAP_ADDR0x14/* dword - consumer capture */ #define ICE1712_REG_CONCAP_COUNT 0x18/* word - current/base count */ #define ICE1712_REG_SERR_SHADOW0x1b/* byte */ @@ -128,14 +128,14 @@ #define ICE1712_DSC_ADDR1 0x02/* dword - base address 1 */ #define ICE1712_DSC_COUNT1 0x03/* word - count 1 */ #define ICE1712_DSC_CONTROL0x04/* byte - control & status */ -#define ICE1712_BUFFER1 0x80/* buffer1 is active */ -#define ICE1712_BUFFER1_AUTO 0x40/* buffer1 auto init */ -#define ICE1712_BUFFER0_AUTO 0x20/* buffer0 auto init */ -#define ICE1712_FLUSH0x10/* flush FIFO */ -#define
Re: [RESEND 0/2] clk: Support for Palmas clk32kg and clk32kgaudio clocks
Quoting Peter Ujfalusi (2014-06-26 23:01:09) > Hi Mike, > > This is a resend of the v2 version of the palmas clock driver which seamingly > missed the 3.16 merge window. I have added Nishanth's Reviewed-by tag to the > patches. Thanks for the resend. Applied to clk-next. Regards, Mike > > Changes since v1: > - binding documentation and driver has been separated based on Nishanth > Menon's > comment > > v2 of the series: > https://lkml.org/lkml/2014/5/6/323 > > v1 of the driver can be found: > https://lkml.org/lkml/2014/4/3/104 > > Palmas class of devices can provide 32K clock(s) to be used by other devices > on the board. Depending on the actual device the provided clocks can be: > CLK32K_KG and CLK32K_KGAUDIO > or only one: > CLK32K_KG (TPS659039 for example) > > Use separate compatible flags for the two 32K clock. > A system which needs or have only one of the 32k clock from > Palmas will need to add node(s) for each clock as separate section > in the dts file. > The two compatible property is: > "ti,palmas-clk32kg" for clk32kg clock > "ti,palmas-clk32kgaudio" for clk32kgaudio clock > > Apart from the register control of the clocks - which is done via > the clock API there is a posibility to enable the external sleep > control. In this way the clock can be enabled/disabled on demand by the > user of the clock. > > Regards, > Peter > --- > Peter Ujfalusi (2): > dt/bindings: Binding documentation for Palmas clk32kg and clk32kgaudio > clocks > clk: Add driver for Palmas clk32kg and clk32kgaudio clocks > > .../bindings/clock/clk-palmas-clk32kg-clocks.txt | 35 +++ > drivers/clk/Kconfig| 7 + > drivers/clk/Makefile | 1 + > drivers/clk/clk-palmas.c | 307 > + > include/dt-bindings/mfd/palmas.h | 18 ++ > 5 files changed, 368 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/clock/clk-palmas-clk32kg-clocks.txt > create mode 100644 drivers/clk/clk-palmas.c > create mode 100644 include/dt-bindings/mfd/palmas.h > > -- > 2.0.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: Re: [PATCH v4] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
On Tue, 2014-07-01 at 11:21 +0900, Masami Hiramatsu wrote: > (2014/06/30 20:36), Michael Ellerman wrote: > > On Mon, 2014-06-30 at 12:14 +0900, Masami Hiramatsu wrote: > >> Ping? :) > > > > Yeah sorry. I started looking at this and got dragged into another mess. > > > > You seem to have duplicated the functionality of arch_deref_entry_point(), > > which was also added for kprobes, and for the same reason - ie. because some > > arches have strange function pointers. Is there some reason you can't use > > it? > > Ah, right! Hmm, it seems some more work to update it. but basically, we can > do. > BTW, is there any other users who need to access the actual function entry > (for > kallsyms case)? Not that I'm aware of. We have had function descriptors on 64-bit powerpc for ever, so in theory by now we should have already found any cases where we need that sort of wrapper. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] net: Fix NETDEV_CHANGE notifier usage causing spurious arp flush
A bug was introduced in NETDEV_CHANGE notifier sequence causing the
arp table to be sometimes spuriously cleared (including manual arp
entries marked permanent), upon network link carrier changes.
The changed argument for the notifier was applied only to a single
caller of NETDEV_CHANGE, missing among others netdev_state_change().
So upon net_carrier events induced by the network, which are
triggering a call to netdev_state_change(), arp_netdev_event() would
decide whether to clear or not arp cache based on random/junk stack
values (a kind of read buffer overflow).
Fixes: be9efd365328 ("net: pass changed flags along with NETDEV_CHANGE event")
Fixes: 6c8b4e3ff81b ("arp: flush arp cache on IFF_NOARP change")
Signed-off-by: Loic Prylli
---
net/core/dev.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 30eedf6..63129d4 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -148,6 +148,9 @@ struct list_head ptype_all __read_mostly; /* Taps */
static struct list_head offload_base __read_mostly;
static int netif_rx_internal(struct sk_buff *skb);
+static int call_netdevice_notifiers_info(unsigned long val,
+struct net_device *dev,
+struct netdev_notifier_info *info);
/*
* The @dev_base_head list is protected by @dev_base_lock and the rtnl
@@ -1207,7 +1210,11 @@ EXPORT_SYMBOL(netdev_features_change);
void netdev_state_change(struct net_device *dev)
{
if (dev->flags & IFF_UP) {
- call_netdevice_notifiers(NETDEV_CHANGE, dev);
+ struct netdev_notifier_change_info change_info;
+
+ change_info.flags_changed = 0;
+ call_netdevice_notifiers_info(NETDEV_CHANGE, dev,
+ _info.info);
rtmsg_ifinfo(RTM_NEWLINK, dev, 0, GFP_KERNEL);
}
}
--
2.0.0.526.g5318336
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [RESEND 2/2] clk: Add driver for Palmas clk32kg and clk32kgaudio clocks
Quoting Peter Ujfalusi (2014-06-29 22:56:55)
> Hi Javier,
>
> On 06/27/2014 09:23 PM, Javier Martinez Canillas wrote:
> > Hello Peter,
> >
> > On Fri, Jun 27, 2014 at 8:01 AM, Peter Ujfalusi
> > wrote:
> >> Palmas class of devices can provide 32K clock(s) to be used by other
> >> devices
> >> on the board. Depending on the actual device the provided clocks can be:
> >> CLK32K_KG and CLK32K_KGAUDIO
> >> or only one:
> >> CLK32K_KG (TPS659039 for example)
> >>
> >> Use separate compatible flags for the two 32K clock.
> >> A system which needs or have only one of the 32k clock from
> >> Palmas will need to add node(s) for each clock as separate section
> >> in the dts file.
> >> The two compatible property is:
> >> "ti,palmas-clk32kg" for clk32kg clock
> >> "ti,palmas-clk32kgaudio" for clk32kgaudio clock
> >>
> >> Apart from the register control of the clocks - which is done via
> >> the clock API there is a posibility to enable the external sleep
> >> control. In this way the clock can be enabled/disabled on demand by the
> >> user of the clock.
> >>
> >> See the documentation for more details.
> >>
> >> Signed-off-by: Peter Ujfalusi
> >> Reviewed-by: Nishanth Menon
>
> >> +static unsigned long palmas_clks_recalc_rate(struct clk_hw *hw,
> >> +unsigned long parent_rate)
> >> +{
> >> + return 32768;
> >> +}
> >
> > I see that other clock drivers using a constant rate return 0 if the
> > clock has not been enabled.
>
> and there are examples when similar fixed clock drivers returns only the clock
> value, like clk-max77686. I can not find clear guidelines neither in the
> documentation or around the header/c files for this.
> Mike, what is the appropriate way of handling the recalc_rate?
You are right that there are no guidelines stating, "don't do that", but
please, "don't do that" ;-)
clk_enable and clk_set_rate are entirely unrelated operations from the
perspective of the Linux clock framework, and mixing these two classes
of operations is a recipe for pain.
>
> > So maybe is more correct to have something
> > like the following?
> >
> > if (__clk_is_enabled(hw->clk))
> > return 32768;
> > else
> > return 0;
So what happens here if this is gateable clock and later on we call
clk_enable on it? The clocks rate will still be zero since
clk_enable/clk_disable do not touch the rate at all.
Regards,
Mike
> >
> > Best regards,
> > Javier
> >
>
>
> --
> Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] rmap: fix pgoff calculation to handle hugepage correctly
On Tue, Jul 01, 2014 at 11:15:40PM +0300, Kirill A. Shutemov wrote:
> On Tue, Jul 01, 2014 at 02:50:21PM -0400, Naoya Horiguchi wrote:
> > On Tue, Jul 01, 2014 at 09:07:39PM +0300, Kirill A. Shutemov wrote:
> > > Why do we need this special case for hugetlb page ->index? Why not use
> > > PAGE_SIZE units there too? Or I miss something?
> >
> > hugetlb pages are never split, so we use larger page cache size for
> > hugetlbfs file (to avoid large sparse page cache tree.)
>
> For transparent huge page cache I would like to have native support in
> page cache radix-tree: since huge pages are always naturally aligned we
> can create a leaf node for it several (RADIX_TREE_MAP_SHIFT -
> HPAGE_PMD_ORDER) levels up by tree, which would cover all indexes in the
> range the huge page represents. This approach should fit hugetlb too. And
> -1 special case for hugetlb.
> But I'm not sure when I'll get time to play with this...
So I'm OK that hugetlb page should have ->index in PAGE_CACHE_SIZE
when transparent huge page is merged. I may try to write patches
on top of your tree after I've done a few series in my work queue.
In order to fix the current problem, I suggest a page_to_pgoff() as a
short-term workaround. I found a few other call sites which can call
on hugepage, so this function help us track such callers.
The similar function seems to be introduced in your transparent huge
page cache tree (page_cache_index()). So this function will be finally
overwritten with it.
Thanks,
Naoya Horiguchi
---
From: Naoya Horiguchi
Date: Tue, 1 Jul 2014 21:38:22 -0400
Subject: [PATCH v2] rmap: fix pgoff calculation to handle hugepage correctly
I triggered VM_BUG_ON() in vma_address() when I try to migrate an anonymous
hugepage with mbind() in the kernel v3.16-rc3. This is because pgoff's
calculation in rmap_walk_anon() fails to consider compound_order() only to
have an incorrect value.
This patch introduces page_to_pgoff(), which gets the page's offset in
PAGE_CACHE_SIZE. Kirill pointed out that page cache tree should natively
handle hugepages, and in order to make hugetlbfs fit it, page->index of
hugetlbfs page should be in PAGE_CACHE_SIZE. This is beyond this patch,
but page_to_pgoff() contains the point to be fixed in a single function.
Signed-off-by: Naoya Horiguchi
---
include/linux/pagemap.h | 12
mm/memory-failure.c | 4 ++--
mm/rmap.c | 10 +++---
3 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
index 0a97b583ee8d..e1474ae18c88 100644
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -399,6 +399,18 @@ static inline struct page *read_mapping_page(struct
address_space *mapping,
}
/*
+ * Get the offset in PAGE_SIZE.
+ * (TODO: hugepage should have ->index in PAGE_SIZE)
+ */
+static inline pgoff_t page_to_pgoff(struct page *page)
+{
+ if (unlikely(PageHeadHuge(page)))
+ return page->index << compound_order(page);
+ else
+ return page->index << (PAGE_CACHE_SHIFT - PAGE_SHIFT);
+}
+
+/*
* Return byte-offset into filesystem object for page.
*/
static inline loff_t page_offset(struct page *page)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index cd8989c1027e..61f05d745e3d 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -435,7 +435,7 @@ static void collect_procs_anon(struct page *page, struct
list_head *to_kill,
if (av == NULL) /* Not actually mapped anymore */
return;
- pgoff = page->index << (PAGE_CACHE_SHIFT - PAGE_SHIFT);
+ pgoff = page_to_pgoff(page);
read_lock(_lock);
for_each_process (tsk) {
struct anon_vma_chain *vmac;
@@ -469,7 +469,7 @@ static void collect_procs_file(struct page *page, struct
list_head *to_kill,
mutex_lock(>i_mmap_mutex);
read_lock(_lock);
for_each_process(tsk) {
- pgoff_t pgoff = page->index << (PAGE_CACHE_SHIFT - PAGE_SHIFT);
+ pgoff_t pgoff = page_to_pgoff(page);
struct task_struct *t = task_early_kill(tsk, force_early);
if (!t)
diff --git a/mm/rmap.c b/mm/rmap.c
index b7e94ebbd09e..22a4a7699cdb 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -517,11 +517,7 @@ void page_unlock_anon_vma_read(struct anon_vma *anon_vma)
static inline unsigned long
__vma_address(struct page *page, struct vm_area_struct *vma)
{
- pgoff_t pgoff = page->index << (PAGE_CACHE_SHIFT - PAGE_SHIFT);
-
- if (unlikely(is_vm_hugetlb_page(vma)))
- pgoff = page->index << huge_page_order(page_hstate(page));
-
+ pgoff_t pgoff = page_to_pgoff(page);
return vma->vm_start + ((pgoff - vma->vm_pgoff) << PAGE_SHIFT);
}
@@ -1639,7 +1635,7 @@ static struct anon_vma *rmap_walk_anon_lock(struct page
*page,
static int rmap_walk_anon(struct page *page, struct rmap_walk_control *rwc)
{
struct anon_vma *anon_vma;
- pgoff_t pgoff = page->index
Re: [PATCH] ARM: dts: Add TMU dt node to monitor the temperature for Exynos3250
Hi Sachin,
On 07/02/2014 12:09 PM, Sachin Kamat wrote:
> On Wed, Jul 2, 2014 at 5:22 AM, Chanwoo Choi wrote:
>> On 07/01/2014 01:10 PM, Sachin Kamat wrote:
>>> Hi Chanwoo,
>>>
>>> On Tue, Jul 1, 2014 at 9:34 AM, Chanwoo Choi wrote:
Hi Sachin,
On 07/01/2014 12:33 PM, Sachin Kamat wrote:
> Hi Chanwoo,
>
> On Tue, Jul 1, 2014 at 6:10 AM, Chanwoo Choi
> wrote:
>> This patch add TMU (Thermal Management Unit) dt node to monitor the high
>> temperature for Exynos3250.
>>
>> Signed-off-by: Chanwoo Choi
>> Acked-by: Kyungmin Park
>> ---
>> This patch has a dependency on following patch [1]:
>> [1] https://lkml.org/lkml/2014/6/30/805
>>
>> arch/arm/boot/dts/exynos3250.dtsi | 10 ++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos3250.dtsi
>> b/arch/arm/boot/dts/exynos3250.dtsi
>> index 3660cab..1e566af 100644
>> --- a/arch/arm/boot/dts/exynos3250.dtsi
>> +++ b/arch/arm/boot/dts/exynos3250.dtsi
>> @@ -192,6 +192,16 @@
>> status = "disabled";
>> };
>>
>> + tmu: tmu@100C {
>> + compatible = "samsung,exynos3250-tmu";
>> + interrupt-parent = <>;
>> + reg = <0x100C 0x100>;
>> + interrupts = <0 216 0>;
>> + clocks = < CLK_TMU_APBIF>;
>> + clock-names = "tmu_apbif";
>> + status = "disabled";
>
> I don't think there would be any board specific properties needed. Hence
> leave the status as enabled (by deleting the above line).
>
I think that if specific board need TMU feature, dts file for specific
board
should include tmu dt node with 'okay' status. The specific board based on
Exynos3250 might not need TMU feature.
>>>
>>> The status field in DT node is not meant for stating the build
>>> configuration but
>>> represents the readiness of the hardware for usage on the platform. If
>>> a particular
>>> board does not need this feature it needs to be disabled in the build
>>> config and only
>>> for any special requirements disable it in board file.
>>
>> TMU (Thermal Management Unit) needs specific regulator for TMU power as
>> following:
>> The regulator for TMU is dependent on board.
>
> In this case it makes sense to leave it disabled in dtsi.
>
Thanks for your review.
Best Regards,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC net-next 01/14] net: filter: split filter.c into two files
Hi Alexei, On Fri, 27 Jun 2014 17:05:53 -0700, Alexei Starovoitov wrote: > BPF is used in several kernel components. This split creates logical boundary > between generic eBPF core and the rest > > kernel/bpf/core.c: eBPF interpreter > > net/core/filter.c: classic->eBPF converter, classic verifiers, socket filters > > This patch only moves functions. > > Signed-off-by: Alexei Starovoitov > --- > kernel/Makefile |1 + > kernel/bpf/Makefile |1 + > kernel/bpf/core.c | 545 > +++ > net/core/filter.c | 520 > 4 files changed, 547 insertions(+), 520 deletions(-) > create mode 100644 kernel/bpf/Makefile > create mode 100644 kernel/bpf/core.c > > diff --git a/kernel/Makefile b/kernel/Makefile > index f2a8b6246ce9..e7360b7c2c0e 100644 > --- a/kernel/Makefile > +++ b/kernel/Makefile > @@ -87,6 +87,7 @@ obj-$(CONFIG_RING_BUFFER) += trace/ > obj-$(CONFIG_TRACEPOINTS) += trace/ > obj-$(CONFIG_IRQ_WORK) += irq_work.o > obj-$(CONFIG_CPU_PM) += cpu_pm.o > +obj-$(CONFIG_NET) += bpf/ But this still requires CONFIG_NET to use bpf. Why not adding CONFIG_BPF and making CONFIG_NET selects it? Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v1] PCI: enable ASPM configuration in PCIE POWERSAVE mode
> -Original Message- > From: Stephen Warren [mailto:swar...@wwwdotorg.org] > Sent: Tuesday, July 01, 2014 8:35 PM > To: Vidya Sagar; bhelg...@google.com; r...@sisk.pl; > nagananda.chumbal...@hp.com; thierry.red...@gmail.com; Stephen > Warren; Krishna Thota; linux-...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Subject: Re: [PATCH v1] PCI: enable ASPM configuration in PCIE POWERSAVE > mode > > On 07/01/2014 01:16 AM, Vidya Sagar wrote: > > commit 1a680b7c moved pcie_aspm_powersave_config_link() out of > > pci_raw_set_power_state() to pci_set_power_state() which would enable > > ASPM. But, with commit db288c9c, which re-introduced the following > > check > > ./drivers/pci/pci.c: pci_set_power_state() > > + /* Check if we're already there */ > > + if (dev->current_state == state) > > + return 0; > > in pci_set_power_state(), call to pcie_aspm_powersave_config_link() is > > never made leaving ASPM broken. > > Fix it by not returning from when the above condition is true, rather, > > jump to ASPM configuration code and exit from there eventually. > > Out of curiosity, was this patch tested by running an umodified mainline > kernel on a Tegra device, or is this simply a port from our downstream kernel, > without any additional upstream testing? I've tested port of this patch on downstream kernel and it works. I've also tested this on thierry's code base (git://gitorious.org/thierryreding/linux.git) which has upstream code for T124-Jetson-tk1. Because of the L0s and L1 exit latencies exhibited by jetson-tk1 on-board Realtek Ethernet controller, subsystem can't enable ASPM states on the end point, but as such I've verified the flow with the help of debug prints and they indicate that the patch is doing its job correctly. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] drm/vmwgfx: correct fb_fix_screeninfo.line_length
On 07/02/2014 05:01 AM, Christopher Friedt wrote: > I have been unable to reproduce this issue in a plethora of test > cases, although granted, I do not have access to a Win7 machine. For > that, I have asked an Ubuntu tester to run through some tests for me. > > https://urldefense.proofpoint.com/v1/url?u=https://bugs.launchpad.net/ubuntu/%2Bsource/xserver-xorg-video-vmware/%2Bbug/1328898/comments/8=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0A=dUdnjNSVc8rpaH6Jc63zkOFO0Bari6xxf72ZYyMo%2Bk4%3D%0A=0c96076761f2340d2de78dcf53d1f2a616d7b932cae49bccbf8268f7520815c5 > > Will post updates as I receive them Indeed, same here, although I only tested on Linux host. I've got confirmation from the device developers that the register in question is indeed a read only register, so I'll post a patch. However, it would be good if you could confirm that the fbdev problem your patch fixed works also without the write to SVGA_REG_BUTES_PER_LINE Thanks, Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/14] cpufreq: cpu0: Extend support beyond CPU0, V2
On 1 July 2014 22:02, Viresh Kumar wrote: > V1: https://lkml.org/lkml/2014/6/25/152 > > Stephen Boyd sent few patches some time back around a new cpufreq driver for > Qualcomm's Krait SoC: https://lkml.org/lkml/2014/6/24/918. > > Krait couldn't use existing cpufreq-cpu0 driver as it doesn't have support for > SoC's with multiple clusters or SoC's which don't share clock line across all > CPUs. > > This patchset is all about extending support beyond CPU0. It can be used for > platforms like Krait or ARM big LITTLE architecture now. > > First two patches add helper routine for of and clk layer, which would be used > by later patches. > > Third one adds space for driver specific data in 'struct cpufreq_policy' and > later ones migrate cpufreq-cpu0 to cpufreq-generic, i.e. can be used for SoCs > which don't share clock lines across all CPUs. > > @Stephen: I haven't added your Tested-by as there were few modifications since > the time you tested it last. > > Pushed here: > Rebased over v3.16-rc3: > git://git.linaro.org/people/viresh.kumar/linux.git cpufreq/cpu0-krait-v2 Hi Stephen, As suggested by you I have updated patch 7/14: cpufreq: cpu0: OPPs can be populated at runtime 12/14: cpufreq: cpu0: Extend support beyond CPU0 and dropped 2/14: clk: Create of_clk_shared_by_cpus() Please see if they look fine and work for you. git://git.linaro.org/people/viresh.kumar/linux.git cpufreq/cpu0-krait-v3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] powerpc/powernv: Check for IRQHAPPENED before sleeping
On Wed, 2014-07-02 at 09:19 +0530, Preeti U Murthy wrote: > Commit 8d6f7c5a: "powerpc/powernv: Make it possible to skip the IRQHAPPENED > check in power7_nap()" added code that prevents cpus from checking for > pending interrupts just before entering sleep state, which is wrong. These > interrupts are delivered during the soft irq disabled state of the cpu. Acked-by: Michael Ellerman cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 Resend 12/14] cpufreq: cpu0: Extend support beyond CPU0
Most of the infrastructure is in place now, with only little left. How to find
siblings ?
Stephen Boyd suggested to compare "clocks" properties from CPU's DT node and
siblings should match. This patch adds another routine find_siblings() which
calls of_property_match() to find if CPUs share clock line or not.
If of_property_match() returns error, we fallback to all CPUs sharing clock line
assumption as existing platforms don't have "clocks" property in all CPU nodes
and would fail from of_property_match().
Cc: devicet...@vger.kernel.org
Signed-off-by: Viresh Kumar
---
V2 Resend: Use of_property_match() directly instead of of_clk_shared_by_cpus()
which would be dropped now.
.../devicetree/bindings/cpufreq/cpufreq-cpu0.txt | 72 --
drivers/cpufreq/cpufreq-cpu0.c | 62 ++-
2 files changed, 128 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
index 366690c..9d65799 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
@@ -1,11 +1,11 @@
-Generic CPU0 cpufreq driver
+Generic cpufreq driver
-It is a generic cpufreq driver for CPU0 frequency management. It
+It is a generic cpufreq driver for frequency management. It
supports both uniprocessor (UP) and symmetric multiprocessor (SMP)
-systems which share clock and voltage across all CPUs.
+systems which may or maynot share clock and voltage across all CPUs.
Both required and optional properties listed below must be defined
-under node /cpus/cpu@0.
+under node /cpus/cpu@x. Where x is the first cpu inside a cluster.
Required properties:
- None
@@ -21,9 +21,16 @@ Optional properties:
- cooling-min-level:
- cooling-max-level:
Please refer to Documentation/devicetree/bindings/thermal/thermal.txt.
+- clocks: If CPU clock is populated from DT, "clocks" property must be copied
to
+ every cpu node sharing clock with cpu@x. Generic cpufreq driver compares
+ "clocks" to find siblings, i.e. to see which CPUs share clock/voltages. If
+ only cpu@0 contains "clocks" property it is assumed that all CPUs share clock
+ line.
Examples:
+1. All CPUs share clock/voltages
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -38,6 +45,8 @@ cpus {
396000 95
198000 85
>;
+ clocks = < CLK_ARM_CLK>;
+ clock-names = "cpu";
clock-latency = <61036>; /* two CLK32 periods */
#cooling-cells = <2>;
cooling-min-level = <0>;
@@ -48,17 +57,72 @@ cpus {
compatible = "arm,cortex-a9";
reg = <1>;
next-level-cache = <>;
+ clocks = < CLK_ARM_CLK>;
};
cpu@2 {
compatible = "arm,cortex-a9";
reg = <2>;
next-level-cache = <>;
+ clocks = < CLK_ARM_CLK>;
};
cpu@3 {
compatible = "arm,cortex-a9";
reg = <3>;
next-level-cache = <>;
+ clocks = < CLK_ARM_CLK>;
+ };
+};
+
+
+2. All CPUs inside a cluster share clock/voltages, there are multiple clusters.
+
+cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ compatible = "arm,cortex-a15";
+ reg = <0>;
+ next-level-cache = <>;
+ operating-points = <
+ /* kHzuV */
+ 792000 110
+ 396000 95
+ 198000 85
+ >;
+ clocks = < CLK_ARM1_CLK>;
+ clock-names = "cpu";
+ clock-latency = <61036>; /* two CLK32 periods */
+ };
+
+ cpu@1 {
+ compatible = "arm,cortex-a15";
+ reg = <1>;
+ next-level-cache = <>;
+ clocks = < CLK_ARM1_CLK>;
+ };
+
+ cpu@100 {
+ compatible = "arm,cortex-a7";
+ reg = <100>;
+ next-level-cache = <>;
+ operating-points = <
+ /* kHzuV */
+ 792000 95
+ 396000 75
+ 198000 45
+ >;
+ clocks = < CLK_ARM2_CLK>;
+ clock-names = "cpu";
+ clock-latency = <61036>; /* two CLK32 periods */
+ };
+
+ cpu@101 {
+ compatible = "arm,cortex-a7";
+ reg = <101>;
+ next-level-cache = <>;
+ clocks = < CLK_ARM2_CLK>;
};
};
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index 44633f6..0f2fe76 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
[PATCH V2 Resend 07/14] cpufreq: cpu0: OPPs can be populated at runtime
OPPs can be populated statically, via DT, or added at run time with
dev_pm_opp_add().
While this driver handles the first case correctly, it would fail to populate
OPPs added at runtime. Because call to of_init_opp_table() would fail as there
are no OPPs in DT and probe will return early.
To fix this, remove error checking and call dev_pm_opp_init_cpufreq_table()
unconditionally.
Update bindings as well.
Suggested-by: Stephen Boyd
Signed-off-by: Viresh Kumar
---
V2 Resend: Update bindings as well
Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt | 6 --
drivers/cpufreq/cpufreq-cpu0.c | 7 ++-
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
index f055515..366690c 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
@@ -8,10 +8,12 @@ Both required and optional properties listed below must be
defined
under node /cpus/cpu@0.
Required properties:
-- operating-points: Refer to Documentation/devicetree/bindings/power/opp.txt
- for details
+- None
Optional properties:
+- operating-points: Refer to Documentation/devicetree/bindings/power/opp.txt
for
+ details. OPPs *must* be supplied either via DT, i.e. this property, or
+ populated at runtime.
- clock-latency: Specify the possible maximum transition latency for clock,
in unit of nanoseconds.
- voltage-tolerance: Specify the CPU voltage tolerance in percentage.
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index b5b8e1c..f47f703 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -164,11 +164,8 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
goto out_put_reg;
}
- ret = of_init_opp_table(cpu_dev);
- if (ret) {
- pr_err("failed to init OPP table: %d\n", ret);
- goto out_put_clk;
- }
+ /* OPPs might be populated at runtime, don't check for error here */
+ of_init_opp_table(cpu_dev);
ret = dev_pm_opp_init_cpufreq_table(cpu_dev, _table);
if (ret) {
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3] powerpc/powernv: Check for IRQHAPPENED before sleeping
Commit 8d6f7c5a: "powerpc/powernv: Make it possible to skip the IRQHAPPENED check in power7_nap()" added code that prevents cpus from checking for pending interrupts just before entering sleep state, which is wrong. These interrupts are delivered during the soft irq disabled state of the cpu. A cpu cannot enter any idle state with pending interrupts because they will never be serviced until the next time the cpu is woken up by some other interrupt. Its only then that the pending interrupts are replayed. This can result in device timeouts or warnings about this cpu being stuck. This patch fixes ths issue by ensuring that cpus check for pending interrupts just before entering any idle state as long as they are not in the path of split core operations. Signed-off-by: Preeti U Murthy --- Chanes in V2: https://lkml.org/lkml/2014/7/1/3 Modified the changelog to add the details of the problem that this patch fixes Changes in V3: V2 assumed that this patch would be useful only in the context of doorbell ipis. But that is not true; this patch is required to correctly handle any type of interrupt delivered in the idle enter path. arch/powerpc/kernel/idle_power7.S |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/idle_power7.S b/arch/powerpc/kernel/idle_power7.S index 2480256..5cf3d36 100644 --- a/arch/powerpc/kernel/idle_power7.S +++ b/arch/powerpc/kernel/idle_power7.S @@ -131,7 +131,7 @@ _GLOBAL(power7_nap) _GLOBAL(power7_sleep) li r3,1 - li r4,0 + li r4,1 b power7_powersave_common /* No return */ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: Add tracepoints for hardware operations
Quoting Stephen Boyd (2014-06-30 18:07:49)
> On 06/30/14 17:52, Steven Rostedt wrote:
> > On Mon, 30 Jun 2014 16:56:39 -0700
> > Stephen Boyd wrote:
> >
> >> @@ -483,10 +486,12 @@ static void clk_unprepare_unused_subtree(struct clk
> >> *clk)
> >> return;
> >>
> >> if (__clk_is_prepared(clk)) {
> >> +trace_clk_unprepare(clk);
> > Does it make sense to do these when clk->ops->unprepared_unused or
> > uprepare is not set?
> >
> > You can use DEFINE_EVENT_CONDITIONAL() and add as condition:
> >
> >clk->ops->unprepared_unused || clk->ops->unprepare
> >
>
> Neat. I don't know if we actually want to do that though. If we always
> record an event even when the hardware doesn't support the operation we
> get information about events happening to the clock from a software
> perspective. If that isn't important, then we can probably just put it
> under the if conditions.
+1 for recording the tree walk even if no hardware operation is backing
it.
Regards,
Mike
>
> >
> >> if (clk->ops->enable) {
> >> ret = clk->ops->enable(clk->hw);
> >> if (ret) {
> >> @@ -945,6 +965,7 @@ static int __clk_enable(struct clk *clk)
> >> return ret;
> > It may make even more sense to add the tracepoints within the if
> > statement. Especially if you have a return on error.
> >
> >
>
> Right. I was thinking that no "clk*_complete" event would mean there was
> some error. Detecting that case is not so easy though. It may be better
> to always have the completion event so we know how long hardware
> operations take and so that error handling is simpler.
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] x86: Find correct 64 bit ramdisk address for microcode early update
When using kexec with 64bit kernel, bzImage and ramdisk could be
loaded above 4G. We need this to get correct ramdisk adress.
Make get_ramdisk_image() global and use it for early microcode updating.
-v2: update changelog.
Signed-off-by: Yinghai Lu
---
arch/x86/include/asm/setup.h|3 +++
arch/x86/kernel/cpu/microcode/amd_early.c | 10 +-
arch/x86/kernel/cpu/microcode/intel_early.c |8
arch/x86/kernel/setup.c | 28 ++--
4 files changed, 26 insertions(+), 23 deletions(-)
Index: linux-2.6/arch/x86/include/asm/setup.h
===
--- linux-2.6.orig/arch/x86/include/asm/setup.h
+++ linux-2.6/arch/x86/include/asm/setup.h
@@ -105,6 +105,9 @@ void *extend_brk(size_t size, size_t ali
RESERVE_BRK(name, sizeof(type) * entries)
extern void probe_roms(void);
+u64 get_ramdisk_image(struct boot_params *bp);
+u64 get_ramdisk_size(struct boot_params *bp);
+
#ifdef __i386__
asmlinkage void __init i386_start_kernel(void);
Index: linux-2.6/arch/x86/kernel/cpu/microcode/amd_early.c
===
--- linux-2.6.orig/arch/x86/kernel/cpu/microcode/amd_early.c
+++ linux-2.6/arch/x86/kernel/cpu/microcode/amd_early.c
@@ -51,12 +51,12 @@ static struct cpio_data __init find_ucod
*/
p = (struct boot_params *)__pa_nodebug(_params);
path= (char *)__pa_nodebug(ucode_path);
- start = (void *)p->hdr.ramdisk_image;
- size= p->hdr.ramdisk_size;
+ start = (void *)(unsigned long)get_ramdisk_image(p);
+ size= get_ramdisk_size(p);
#else
path= ucode_path;
- start = (void *)(boot_params.hdr.ramdisk_image + PAGE_OFFSET);
- size= boot_params.hdr.ramdisk_size;
+ start = (void *)(get_ramdisk_image(_params) + PAGE_OFFSET);
+ size= get_ramdisk_size(_params);
#endif
return find_cpio_data(path, start, size, );
@@ -371,7 +371,7 @@ int __init save_microcode_in_initrd_amd(
*/
if (relocated_ramdisk)
container = (u8 *)(__va(relocated_ramdisk) +
-(cont - boot_params.hdr.ramdisk_image));
+(cont - get_ramdisk_size(_params)));
if (ucode_new_rev)
pr_info("microcode: updated early to new patch_level=0x%08x\n",
Index: linux-2.6/arch/x86/kernel/cpu/microcode/intel_early.c
===
--- linux-2.6.orig/arch/x86/kernel/cpu/microcode/intel_early.c
+++ linux-2.6/arch/x86/kernel/cpu/microcode/intel_early.c
@@ -733,8 +733,8 @@ load_ucode_intel_bsp(void)
struct boot_params *boot_params_p;
boot_params_p = (struct boot_params *)__pa_nodebug(_params);
- ramdisk_image = boot_params_p->hdr.ramdisk_image;
- ramdisk_size = boot_params_p->hdr.ramdisk_size;
+ ramdisk_image = get_ramdisk_image(boot_params_p);
+ ramdisk_size = get_ramdisk_size(boot_params_p);
initrd_start_early = ramdisk_image;
initrd_end_early = initrd_start_early + ramdisk_size;
@@ -743,8 +743,8 @@ load_ucode_intel_bsp(void)
(unsigned long *)__pa_nodebug(_saved_in_initrd),
initrd_start_early, initrd_end_early, );
#else
- ramdisk_image = boot_params.hdr.ramdisk_image;
- ramdisk_size = boot_params.hdr.ramdisk_size;
+ ramdisk_image = get_ramdisk_image(_params);
+ ramdisk_size = get_ramdisk_size(_params);
initrd_start_early = ramdisk_image + PAGE_OFFSET;
initrd_end_early = initrd_start_early + ramdisk_size;
Index: linux-2.6/arch/x86/kernel/setup.c
===
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -299,19 +299,19 @@ u64 relocated_ramdisk;
#ifdef CONFIG_BLK_DEV_INITRD
-static u64 __init get_ramdisk_image(void)
+u64 __init get_ramdisk_image(struct boot_params *bp)
{
- u64 ramdisk_image = boot_params.hdr.ramdisk_image;
+ u64 ramdisk_image = bp->hdr.ramdisk_image;
- ramdisk_image |= (u64)boot_params.ext_ramdisk_image << 32;
+ ramdisk_image |= (u64)bp->ext_ramdisk_image << 32;
return ramdisk_image;
}
-static u64 __init get_ramdisk_size(void)
+u64 __init get_ramdisk_size(struct boot_params *bp)
{
- u64 ramdisk_size = boot_params.hdr.ramdisk_size;
+ u64 ramdisk_size = bp->hdr.ramdisk_size;
- ramdisk_size |= (u64)boot_params.ext_ramdisk_size << 32;
+ ramdisk_size |= (u64)bp->ext_ramdisk_size << 32;
return ramdisk_size;
}
@@ -320,8 +320,8 @@ static u64 __init get_ramdisk_size(void)
static void __init relocate_initrd(void)
{
/* Assume only end is not page aligned */
- u64 ramdisk_image = get_ramdisk_image();
- u64 ramdisk_size = get_ramdisk_size();
+ u64 ramdisk_image =
Re: [PATCH v2 1/1] clk: Fix build warnings
Quoting Sachin Kamat (2014-06-30 23:26:34)
> ‘all_lists’ and ‘orphan_list’ is accessed only when DEBUG_FS is defined.
> Thus, make their compilation conditional to fix the below warnings introduced
> by commit 27b8d5f723 ("clk: flatten clk tree in debugfs"):
> drivers/clk/clk.c:40:27: warning: ‘all_lists’ defined but not used
> [-Wunused-variable]
> drivers/clk/clk.c:46:27: warning: ‘orphan_list’ defined but not used
> [-Wunused-variable]
>
> Signed-off-by: Sachin Kamat
> Cc: Peter De Schrijver
Applied.
Thanks,
Mike
> ---
> Changes since v1:
> Moved the definitions under already existing #ifdefs.
> ---
> drivers/clk/clk.c | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 7dfb2f308b35..958967d141ee 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -36,17 +36,6 @@ static HLIST_HEAD(clk_root_list);
> static HLIST_HEAD(clk_orphan_list);
> static LIST_HEAD(clk_notifier_list);
>
> -static struct hlist_head *all_lists[] = {
> - _root_list,
> - _orphan_list,
> - NULL,
> -};
> -
> -static struct hlist_head *orphan_list[] = {
> - _orphan_list,
> - NULL,
> -};
> -
> /*** locking ***/
> static void clk_prepare_lock(void)
> {
> @@ -111,6 +100,17 @@ static void clk_enable_unlock(unsigned long flags)
> static struct dentry *rootdir;
> static int inited = 0;
>
> +static struct hlist_head *all_lists[] = {
> + _root_list,
> + _orphan_list,
> + NULL,
> +};
> +
> +static struct hlist_head *orphan_list[] = {
> + _orphan_list,
> + NULL,
> +};
> +
> static void clk_summary_show_one(struct seq_file *s, struct clk *c, int
> level)
> {
> if (!c)
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] cpufreq: cpu0: Extend support beyond CPU0
On 2 July 2014 03:30, Mike Turquette wrote: > I can't help but think this is a pretty ugly solution. Why not specify Thanks :) > the nature of the cpu clock(s) in DT directly? There was a thread > already that discussed adding such a property to the CPU DT binding but > it seems to have gone cold[1]. Furthermore my mailer sucks and I see now > that my response to that thread never hit the list due to mangled > headers. Here is a copy/paste of my response to the aforementioned > thread: Atleast I received it. Yes, I do agree that we need to get this from the DT in more elegant way but it is going to take some time in doing that, and probably some people are working on it as that might be used in scheduler-cpufreq coordination as well.. For now we can go ahead and make it workable, even if it isn't that elegant and update it later on. Thanks for your inputs. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
net: pretty odd panic in netfilter
Hi all, While fuzzing with trinity inside a KVM tools guest running the latest -next kernel I've stumbled on a pretty odd corruption(?) in the code - a pretty odd one. Here's the issue I've hit: [ 3640.805823] BUG: unable to handle kernel paging request at ff84 [ 3640.808115] IP: nf_nat_packet (net/netfilter/nf_nat_core.c:482) [ 3640.810049] PGD 22031067 PUD 22033067 PMD 0 [ 3640.810120] Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 3640.810120] Dumping ftrace buffer: [ 3640.810120](ftrace buffer empty) [ 3640.810120] Modules linked in: [ 3640.810120] CPU: 4 PID: 5017 Comm: trinity-c192 Tainted: GW 3.16.0-rc3-next-20140701-sasha-00023-g4eb2544-dirty #759 [ 3640.810120] task: 88014d5a3000 ti: 880146088000 task.ti: 880146088000 [ 3640.810120] RIP: nf_nat_packet (net/netfilter/nf_nat_core.c:482) [ 3640.810120] RSP: 0018:88014608b958 EFLAGS: 00010206 [ 3640.810120] RAX: 0001 RBX: 0001 RCX: 8801548a7a00 [ 3640.810120] RDX: 0003 RSI: 0002 RDI: 88013108 [ 3640.810120] RBP: 88014608b9a8 R08: R09: 0002 [ 3640.810120] R10: R11: R12: 8801548a7a80 [ 3640.810120] R13: 88013108 R14: a32e8d50 R15: 8803346b1160 [ 3640.810120] FS: 7f7e56497700() GS:880144e0() knlGS: [ 3640.810120] CS: 0010 DS: ES: CR0: 8005003b [ 3640.840752] CR2: ff84 CR3: 00016a997000 CR4: 06a0 [ 3640.840752] Stack: [ 3640.840752] 8803346b1160 0014 19e906c0 [ 3640.840752] 0002 19e906c0 8801548a7a80 0001 [ 3640.840752] 88013108 a32e8d50 88014608ba28 a00ffb7e [ 3640.840752] Call Trace: [ 3640.840752] nf_nat_ipv4_fn (net/ipv4/netfilter/iptable_nat.c:136) [ 3640.840752] nf_nat_ipv4_local_fn (net/ipv4/netfilter/iptable_nat.c:219) [ 3640.840752] ? __ip_append_data.isra.33 (include/net/dst.h:461) [ 3640.840752] nf_iterate (net/netfilter/core.c:150) [ 3640.840752] ? __ip_append_data.isra.33 (include/net/dst.h:461) [ 3640.840752] nf_hook_slow (net/netfilter/core.c:185) [ 3640.840752] ? __ip_append_data.isra.33 (include/net/dst.h:461) [ 3640.840752] __ip_local_out (net/ipv4/ip_output.c:102) [ 3640.840752] ip_local_out_sk (net/ipv4/ip_output.c:109) [ 3640.840752] ip_send_skb (net/ipv4/ip_output.c:1411) [ 3640.840752] ip_push_pending_frames (net/ipv4/ip_output.c:1431) [ 3640.840752] raw_sendmsg (net/ipv4/raw.c:619) [ 3640.840752] ? sched_clock (./arch/x86/include/asm/paravirt.h:192 arch/x86/kernel/tsc.c:305) [ 3640.840752] ? get_parent_ip (kernel/sched/core.c:2550) [ 3640.840752] ? get_parent_ip (kernel/sched/core.c:2550) [ 3640.840752] ? inet_sendmsg (include/linux/rcupdate.h:906 include/net/sock.h:833 include/net/sock.h:852 net/ipv4/af_inet.c:730) [ 3640.840752] ? inet_sendmsg (include/linux/rcupdate.h:906 include/net/sock.h:833 include/net/sock.h:852 net/ipv4/af_inet.c:730) [ 3640.840752] inet_sendmsg (net/ipv4/af_inet.c:737) [ 3640.840752] sock_sendmsg (net/socket.c:654) [ 3640.840752] ? might_fault (mm/memory.c:3741) [ 3640.840752] ? might_fault (mm/memory.c:3740) [ 3640.840752] ? vtime_account_user (kernel/sched/cputime.c:687) [ 3640.840752] ? move_addr_to_kernel (./arch/x86/include/asm/uaccess.h:713 net/socket.c:197) [ 3640.840752] SYSC_sendto (net/socket.c:1812) [ 3640.840752] ? vtime_account_user (kernel/sched/cputime.c:687) [ 3640.840752] ? check_preemption_disabled (lib/smp_processor_id.c:42) [ 3640.840752] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2557 kernel/locking/lockdep.c:2599) [ 3640.840752] ? trace_hardirqs_on (kernel/locking/lockdep.c:2607) [ 3640.840752] ? syscall_trace_enter (include/linux/context_tracking.h:27 arch/x86/kernel/ptrace.c:1461) [ 3640.840752] SyS_sendto (net/socket.c:1779) [ 3640.840752] tracesys (arch/x86/kernel/entry_64.S:542) [ 3640.840752] Code: 4c 89 65 e8 49 89 cc 0f 97 c1 83 fa 01 0f 95 c0 48 89 5d e0 31 db 83 fa 04 4c 89 6d f0 0f 95 c3 4c 89 75 f8 21 55 55 fb 01 48 19 48 83 e2 f0 48 83 c2 20 48 89 d0 48 83 f0 30 84 c9 48 0f 45 [ 3640.840752] RIP nf_nat_packet (net/netfilter/nf_nat_core.c:482) [ 3640.840752] RSP [ 3640.840752] CR2: ff84 Two odd things here: 1. The code section seems to point mid-instruction: 19dc: 0f 95 c3setne %bl 19df: 4c 89 75 f8 mov%r14,-0x8(%rbp) 19e3: 21 c3 and%eax,%ebx 19e5: 83 fb 01cmp$0x1,%ebx 19e8: 48 19 d2sbb%rdx,%rdx <=== The end of this (0xd2) 19eb: 48 83 e2 f0 and$0xfff0,%rdx 19ef: 48 83 c2 20 add$0x20,%rdx 19f3: 48 89 d0mov%rdx,%rax 19f6: 48 83 f0 30 xor$0x30,%rax 2. There isn't anything in that a
Re: [RESEND PATCH 1/2] ARM: AM43xx: hwmod: add DSS hwmod data
Hi, On Fri, Jun 13, 2014 at 07:11:58PM +, Paul Walmsley wrote: > Hi Felipe, Tomi, > > On Fri, 13 Jun 2014, Felipe Balbi wrote: > > > On Fri, Jun 13, 2014 at 11:15:46AM -0500, Felipe Balbi wrote: > > > From: Sathya Prakash M R > > > > > > Add DSS hwmod data for AM43xx. > > > > > > Cc: Andrew Morton > > > Acked-by: Rajendra Nayak > > > Signed-off-by: Sathya Prakash M R > > > Signed-off-by: Tomi Valkeinen > > > Signed-off-by: Felipe Balbi > > > --- > > > > > > Note that this patch was originally send on May 9th [1], changes were > > > requested > > > and a new version was sent on May 19th [2], then on May 27th [3] Tomi > > > pinged > > > maintainer again and go no response. > > > > > > Without this patch, we cannot get display working on any AM437x devices. > > > > > > [1] http://marc.info/?l=linux-arm-kernel=139963677925227=2 > > > [2] http://marc.info/?l=linux-arm-kernel=140049799425512=2 > > > [3] http://marc.info/?l=linux-arm-kernel=140117232826754=2 > > > > > > arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 98 > > > ++ > > > arch/arm/mach-omap2/prcm43xx.h | 1 + > > > 2 files changed, 99 insertions(+) > > Sorry for the delay on this. Have been corresponding with TI management > to figure out what to do about patches for AM43xx. I don't have boards or > public documentation for these devices, so it's impossible for me to documentation is now available publicly http://www.ti.com/product/AM4379 -- balbi signature.asc Description: Digital signature
Re: [PATCH v2] firmware loader: inform direct failure when udev loader is disabled
On Wed, Jul 2, 2014 at 11:07 AM, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > Now that the udev firmware loader is optional request_firmware() > will not provide any information on the kernel ring buffer if > direct firmware loading failed and udev firmware loading is disabled. > If no information is needed request_firmware_direct() should be used > for optional firmware, at which point drivers can take on the onus > over informing of any failures, if udev firmware loading is disabled > though we should at the very least provide some sort of information > as when the udev loader was enabled by default back in the days. > > With this change with a simple firmware load test module [0]: > > Example output without FW_LOADER_USER_HELPER_FALLBACK > > platform fake-dev.0: Direct firmware load for fake.bin failed > with error -2 > > Example with FW_LOADER_USER_HELPER_FALLBACK > > platform fake-dev.0: Direct firmware load for fake.bin failed with error -2 > platform fake-dev.0: Falling back to user helper > > Without this change without FW_LOADER_USER_HELPER_FALLBACK we > get no output logged upon failure. > > Cc: Tom Gundersen > Cc: Ming Lei > Cc: Greg Kroah-Hartman > Cc: Abhay Salunke > Cc: Stefan Roese > Cc: Arnd Bergmann > Cc: Kay Sievers > Cc: Takashi Iwai > Signed-off-by: Luis R. Rodriguez Looks fine, also it is a cleanup. Acked-by: Ming Lei Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Power Supply Subsystem Maintainer
Andrew Morton, Appreciate your help to sort out the power supply maintainer issue. The subsystem is not active after February 2014. No response from maintainer and the last commit on git://git.infradead.org/battery-2.6 was on 2014-02-01. Appreciate your help. -Jenny On Mon, Jun 30, 2014 at 01:26:46PM +0200, Belisko Marek wrote: > Same on my side (some pending patches) but there was already > discussion: https://lkml.org/lkml/2014/5/16/504 > > On Mon, Jun 30, 2014 at 1:16 PM, Jenny Tc wrote: > > Hi all, > > > > I have few pending patches on power supply subsystem. So far I haven't seen > > any response from the power supply maintainers. As per the MAINTAINERS > > entry, > > the susbsystem is owned by "Dmitry Eremin-Solenikov ". > > But not sure he still maintains the susbsystem, as I don't see any response > > from him. Also the last commit I could see on > > git://git.infradead.org/battery-2.6 > > is on Feb this year. I would appreciate if anyone could clarify who really > > maintains the power supply subsystem. > > > > Thanks > > Jenny > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ARM: dts: Add TMU dt node to monitor the temperature for Exynos3250
On Wed, Jul 2, 2014 at 5:22 AM, Chanwoo Choi wrote:
> On 07/01/2014 01:10 PM, Sachin Kamat wrote:
>> Hi Chanwoo,
>>
>> On Tue, Jul 1, 2014 at 9:34 AM, Chanwoo Choi wrote:
>>> Hi Sachin,
>>>
>>> On 07/01/2014 12:33 PM, Sachin Kamat wrote:
Hi Chanwoo,
On Tue, Jul 1, 2014 at 6:10 AM, Chanwoo Choi wrote:
> This patch add TMU (Thermal Management Unit) dt node to monitor the high
> temperature for Exynos3250.
>
> Signed-off-by: Chanwoo Choi
> Acked-by: Kyungmin Park
> ---
> This patch has a dependency on following patch [1]:
> [1] https://lkml.org/lkml/2014/6/30/805
>
> arch/arm/boot/dts/exynos3250.dtsi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos3250.dtsi
> b/arch/arm/boot/dts/exynos3250.dtsi
> index 3660cab..1e566af 100644
> --- a/arch/arm/boot/dts/exynos3250.dtsi
> +++ b/arch/arm/boot/dts/exynos3250.dtsi
> @@ -192,6 +192,16 @@
> status = "disabled";
> };
>
> + tmu: tmu@100C {
> + compatible = "samsung,exynos3250-tmu";
> + interrupt-parent = <>;
> + reg = <0x100C 0x100>;
> + interrupts = <0 216 0>;
> + clocks = < CLK_TMU_APBIF>;
> + clock-names = "tmu_apbif";
> + status = "disabled";
I don't think there would be any board specific properties needed. Hence
leave the status as enabled (by deleting the above line).
>>>
>>> I think that if specific board need TMU feature, dts file for specific board
>>> should include tmu dt node with 'okay' status. The specific board based on
>>> Exynos3250 might not need TMU feature.
>>
>> The status field in DT node is not meant for stating the build configuration
>> but
>> represents the readiness of the hardware for usage on the platform. If
>> a particular
>> board does not need this feature it needs to be disabled in the build
>> config and only
>> for any special requirements disable it in board file.
>
> TMU (Thermal Management Unit) needs specific regulator for TMU power as
> following:
> The regulator for TMU is dependent on board.
In this case it makes sense to leave it disabled in dtsi.
--
Regards,
Sachin.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] firmware loader: inform direct failure when udev loader is disabled
From: "Luis R. Rodriguez"
Now that the udev firmware loader is optional request_firmware()
will not provide any information on the kernel ring buffer if
direct firmware loading failed and udev firmware loading is disabled.
If no information is needed request_firmware_direct() should be used
for optional firmware, at which point drivers can take on the onus
over informing of any failures, if udev firmware loading is disabled
though we should at the very least provide some sort of information
as when the udev loader was enabled by default back in the days.
With this change with a simple firmware load test module [0]:
Example output without FW_LOADER_USER_HELPER_FALLBACK
platform fake-dev.0: Direct firmware load for fake.bin failed
with error -2
Example with FW_LOADER_USER_HELPER_FALLBACK
platform fake-dev.0: Direct firmware load for fake.bin failed with error -2
platform fake-dev.0: Falling back to user helper
Without this change without FW_LOADER_USER_HELPER_FALLBACK we
get no output logged upon failure.
Cc: Tom Gundersen
Cc: Ming Lei
Cc: Greg Kroah-Hartman
Cc: Abhay Salunke
Cc: Stefan Roese
Cc: Arnd Bergmann
Cc: Kay Sievers
Cc: Takashi Iwai
Signed-off-by: Luis R. Rodriguez
---
This v2 modifies the error to always be called and only in the
request_firmware_direct case do we not send smoke signals.
drivers/base/firmware_class.c | 13 +++--
include/linux/firmware.h | 15 ---
2 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 46ea5f4..60d0e53 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -109,6 +109,7 @@ static inline long firmware_loading_timeout(void)
#else
#define FW_OPT_FALLBACK0
#endif
+#define FW_OPT_DIRECT_ONLY (1U << 3)
struct firmware_cache {
/* firmware_buf instance will be added into the below list */
@@ -1116,10 +1117,11 @@ _request_firmware(const struct firmware **firmware_p,
const char *name,
ret = fw_get_filesystem_firmware(device, fw->priv);
if (ret) {
- if (opt_flags & FW_OPT_USERHELPER) {
+ if (!(opt_flags & FW_OPT_DIRECT_ONLY))
dev_warn(device,
-"Direct firmware load failed with error %d\n",
-ret);
+"Direct firmware load for %s failed with error
%d\n",
+name, ret);
+ if (opt_flags & FW_OPT_USERHELPER) {
dev_warn(device, "Falling back to user helper\n");
ret = fw_load_from_user_helper(fw, name, device,
opt_flags, timeout);
@@ -1176,7 +1178,6 @@ request_firmware(const struct firmware **firmware_p,
const char *name,
}
EXPORT_SYMBOL(request_firmware);
-#ifdef CONFIG_FW_LOADER_USER_HELPER_FALLBACK
/**
* request_firmware: - load firmware directly without usermode helper
* @firmware_p: pointer to firmware image
@@ -1193,12 +1194,12 @@ int request_firmware_direct(const struct firmware
**firmware_p,
{
int ret;
__module_get(THIS_MODULE);
- ret = _request_firmware(firmware_p, name, device, FW_OPT_UEVENT);
+ ret = _request_firmware(firmware_p, name, device,
+ FW_OPT_UEVENT | FW_OPT_DIRECT_ONLY);
module_put(THIS_MODULE);
return ret;
}
EXPORT_SYMBOL_GPL(request_firmware_direct);
-#endif
/**
* release_firmware: - release the resource associated with a firmware image
diff --git a/include/linux/firmware.h b/include/linux/firmware.h
index 67e5b80..5c41c5e 100644
--- a/include/linux/firmware.h
+++ b/include/linux/firmware.h
@@ -45,6 +45,8 @@ int request_firmware_nowait(
struct module *module, bool uevent,
const char *name, struct device *device, gfp_t gfp, void *context,
void (*cont)(const struct firmware *fw, void *context));
+int request_firmware_direct(const struct firmware **fw, const char *name,
+ struct device *device);
void release_firmware(const struct firmware *fw);
#else
@@ -66,13 +68,12 @@ static inline void release_firmware(const struct firmware
*fw)
{
}
-#endif
+static inline int request_firmware_direct(const struct firmware **fw,
+ const char *name,
+ struct device *device)
+{
+ return -EINVAL;
+}
-#ifdef CONFIG_FW_LOADER_USER_HELPER_FALLBACK
-int request_firmware_direct(const struct firmware **fw, const char *name,
- struct device *device);
-#else
-#define request_firmware_directrequest_firmware
#endif
-
#endif
--
2.0.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
Re: [PATCH 1/1] drm/vmwgfx: correct fb_fix_screeninfo.line_length
I have been unable to reproduce this issue in a plethora of test cases, although granted, I do not have access to a Win7 machine. For that, I have asked an Ubuntu tester to run through some tests for me. https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-vmware/+bug/1328898/comments/8 Will post updates as I receive them. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: one doubt about mmc_sdio_init_card function
On 07/01/2014 01:39 PM, Fu, Zhonghui wrote:
>
> Hi, all
>
> The mmc_sdio_init_card(drivers/mmc/core/sdio.c) function calls
> mmc_alloc_card(drivers/mmc/core/bus.c) function to allocate a card structure.
> card->dev.bus is assigned with mmc_bus_type in mmc_alloc_card function. Why
> not assign sdio_bus_type to card->dev.bus?
sdio card, mmc card, sd card are all devices on the mmc bus, hence their
bus type is set to mmc_bus_type.
sdio function device is a device on the sdio bus, hence its bus type is
sdio_bus_type.
Hope this helps,
Aaron
>
>
> struct mmc_card *mmc_alloc_card(struct mmc_host *host, struct device_type
> *type)
> {
> struct mmc_card *card;
>
> card = kzalloc(sizeof(struct mmc_card), GFP_KERNEL);
> if (!card)
> return ERR_PTR(-ENOMEM);
>
> card->host = host;
>
> device_initialize(>dev);
>
> card->dev.parent = mmc_classdev(host);
> card->dev.bus = _bus_type;
> card->dev.release = mmc_release_card;
> card->dev.type = type;
>
> return card;
> }
>
>
> Thanks,
> Zhonghui
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] ASoC: sirf: Add device tree binding for the USP audio device
Signed-off-by: Rongjun Ying
---
.../devicetree/bindings/sound/sirf-usp.txt | 27 ++
1 file changed, 27 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/sirf-usp.txt
diff --git a/Documentation/devicetree/bindings/sound/sirf-usp.txt
b/Documentation/devicetree/bindings/sound/sirf-usp.txt
new file mode 100644
index 000..02f85b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/sirf-usp.txt
@@ -0,0 +1,27 @@
+* SiRF SoC USP module
+
+Required properties:
+- compatible: "sirf,prima2-usp-pcm"
+- reg: Base address and size entries:
+- dmas: List of DMA controller phandle and DMA request line ordered pairs.
+- dma-names: Identifier string for each DMA request line in the dmas property.
+ These strings correspond 1:1 with the ordered pairs in dmas.
+
+ One of the DMA channels will be responsible for transmission (should be
+ named "tx") and one for reception (should be named "rx").
+
+- clocks: USP controller clock source
+- pinctrl-names: Must contain a "default" entry.
+- pinctrl-NNN: One property must exist for each entry in pinctrl-names.
+
+Example:
+usp0: usp@b008 {
+ compatible = "sirf,prima2-usp-pcm";
+ reg = <0xb008 0x1>;
+ clocks = < 28>;
+ dmas = < 1>, < 2>;
+ dma-names = "rx", "tx";
+ pinctrl-names = "default";
+ pinctrl-0 = <_only_utfs_pins_a>;
+};
+
--
1.9.3
Member of the CSR plc group of companies. CSR plc registered in England and
Wales, registered number 4187346, registered office Churchill House, Cambridge
Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Keep up to date with CSR on our
technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube,
www.youtube.com/user/CSRplc, Facebook,
www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at
www.twitter.com/CSR_plc.
New for 2014, you can now access the wide range of products powered by aptX at
www.aptx.com.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] ASoC: sirf: Add audio usp interface driver
This patch adds ASoC support for SiRF SoCs USP interface.
Features include:
1. Only support slave mode.
2. Support I2S and DSP_A mode.
3. Support S16_LE, S24_LE and S24_3LE formats.
4. Support stereo and mono mode.
5. The biggest Support is 192Khz sample rate.
Signed-off-by: Rongjun Ying
---
-v2:
1. Remove extra variable
2. Use the switch statement instead of if/else
3. Fixed some indentation
sound/soc/sirf/Kconfig| 6 +
sound/soc/sirf/Makefile | 2 +
sound/soc/sirf/sirf-usp.c | 415 ++
sound/soc/sirf/sirf-usp.h | 293
4 files changed, 716 insertions(+)
create mode 100644 sound/soc/sirf/sirf-usp.c
create mode 100644 sound/soc/sirf/sirf-usp.h
diff --git a/sound/soc/sirf/Kconfig b/sound/soc/sirf/Kconfig
index 89e8942..840058d 100644
--- a/sound/soc/sirf/Kconfig
+++ b/sound/soc/sirf/Kconfig
@@ -12,3 +12,9 @@ config SND_SOC_SIRF_AUDIO
config SND_SOC_SIRF_AUDIO_PORT
select REGMAP_MMIO
tristate
+
+config SND_SOC_SIRF_USP
+ tristate "SoC Audio (I2S protocol) for SiRF SoC USP interface"
+ depends on SND_SOC_SIRF
+ select REGMAP_MMIO
+ tristate
diff --git a/sound/soc/sirf/Makefile b/sound/soc/sirf/Makefile
index 913b932..dd917f2 100644
--- a/sound/soc/sirf/Makefile
+++ b/sound/soc/sirf/Makefile
@@ -1,5 +1,7 @@
snd-soc-sirf-audio-objs := sirf-audio.o
snd-soc-sirf-audio-port-objs := sirf-audio-port.o
+snd-soc-sirf-usp-objs := sirf-usp.o
obj-$(CONFIG_SND_SOC_SIRF_AUDIO) += snd-soc-sirf-audio.o
obj-$(CONFIG_SND_SOC_SIRF_AUDIO_PORT) += snd-soc-sirf-audio-port.o
+obj-$(CONFIG_SND_SOC_SIRF_USP) += snd-soc-sirf-usp.o
diff --git a/sound/soc/sirf/sirf-usp.c b/sound/soc/sirf/sirf-usp.c
new file mode 100644
index 000..bdf6aae
--- /dev/null
+++ b/sound/soc/sirf/sirf-usp.c
@@ -0,0 +1,415 @@
+/*
+ * SiRF USP in I2S/DSP mode
+ *
+ * Copyright (c) 2011 Cambridge Silicon Radio Limited, a CSR plc group company.
+ *
+ * Licensed under GPLv2 or later.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "sirf-usp.h"
+
+struct sirf_usp {
+ struct regmap *regmap;
+ struct clk *clk;
+ u32 mode1_reg;
+ u32 mode2_reg;
+ int daifmt_format;
+ struct snd_dmaengine_dai_dma_data playback_dma_data;
+ struct snd_dmaengine_dai_dma_data capture_dma_data;
+};
+
+static void sirf_usp_tx_enable(struct sirf_usp *usp)
+{
+ regmap_update_bits(usp->regmap, USP_TX_FIFO_OP,
+ USP_TX_FIFO_RESET, USP_TX_FIFO_RESET);
+ regmap_write(usp->regmap, USP_TX_FIFO_OP, 0);
+
+ regmap_update_bits(usp->regmap, USP_TX_FIFO_OP,
+ USP_TX_FIFO_START, USP_TX_FIFO_START);
+
+ regmap_update_bits(usp->regmap, USP_TX_RX_ENABLE,
+ USP_TX_ENA, USP_TX_ENA);
+}
+
+static void sirf_usp_tx_disable(struct sirf_usp *usp)
+{
+ regmap_update_bits(usp->regmap, USP_TX_RX_ENABLE,
+ USP_TX_ENA, ~USP_TX_ENA);
+ /* FIFO stop */
+ regmap_write(usp->regmap, USP_TX_FIFO_OP, 0);
+}
+
+static void sirf_usp_rx_enable(struct sirf_usp *usp)
+{
+ regmap_update_bits(usp->regmap, USP_RX_FIFO_OP,
+ USP_RX_FIFO_RESET, USP_RX_FIFO_RESET);
+ regmap_write(usp->regmap, USP_RX_FIFO_OP, 0);
+
+ regmap_update_bits(usp->regmap, USP_RX_FIFO_OP,
+ USP_RX_FIFO_START, USP_RX_FIFO_START);
+
+ regmap_update_bits(usp->regmap, USP_TX_RX_ENABLE,
+ USP_RX_ENA, USP_RX_ENA);
+}
+
+static void sirf_usp_rx_disable(struct sirf_usp *usp)
+{
+ regmap_update_bits(usp->regmap, USP_TX_RX_ENABLE,
+ USP_RX_ENA, ~USP_RX_ENA);
+ /* FIFO stop */
+ regmap_write(usp->regmap, USP_RX_FIFO_OP, 0);
+}
+
+static int sirf_usp_pcm_dai_probe(struct snd_soc_dai *dai)
+{
+ struct sirf_usp *usp = snd_soc_dai_get_drvdata(dai);
+ snd_soc_dai_init_dma_data(dai, >playback_dma_data,
+ >capture_dma_data);
+ return 0;
+}
+
+static int sirf_usp_pcm_set_dai_fmt(struct snd_soc_dai *dai,
+ unsigned int fmt)
+{
+ struct sirf_usp *usp = snd_soc_dai_get_drvdata(dai);
+
+ /* set master/slave audio interface */
+ switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
+ case SND_SOC_DAIFMT_CBM_CFM:
+ break;
+ default:
+ dev_err(dai->dev, "Only CBM and CFM supported\n");
+ return -EINVAL;
+ }
+
+ switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
+ case SND_SOC_DAIFMT_I2S:
+ case SND_SOC_DAIFMT_DSP_A:
+ usp->daifmt_format = (fmt & SND_SOC_DAIFMT_FORMAT_MASK);
+ break;
+ default:
+ dev_err(dai->dev, "Only I2S and DSP_A format supported\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int sirf_usp_i2s_startup(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ struct sirf_usp *usp =
Re: [PATCH] sched: select 'idle' cfs_rq per task-group to prevent tg-internal imbalance
On 07/01/2014 04:56 PM, Peter Zijlstra wrote: > On Tue, Jul 01, 2014 at 04:38:58PM +0800, Michael wang wrote: [snip] >> Currently when dbench running with stress, it could only gain one CPU, >> and cpu-cgroup cpu.shares is meaningless, is there any good methods to >> address that? > > So as far as I understood this is because of 'other' tasks; these other > tasks have never been fully qualified, but I suspect they're workqueue > thingies. One solution would be to have work run in the same cgroup as > the task creating it. Yes, they are kworkers. > > The thing is, this is not a scheduler problem, so we should not fix it > in the scheduler. I won't argue on that point, while even we get rid of the cgroup stuff, let's say we just run 12 stress, then 'dbench 6' will suffered a low performance too, this kind of mixed workloads is not treated well enough from the view of dbench, and no methods provided by scheduler could address that... The opinion on features actually make me a little confusing... I used to think the scheduler is willing on providing kinds of way to adapt itself to different situation, and some features do help on that, make them only a debug option make the scheduler more static to users, but I know that's not what I should touched... Anyway, the problem is still there and seems like we have to adopt some optional solution to address it, we'll still working and practice on that, please let us know if you have any ideas we could help on ;-) Regards, Michael Wang > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/2] ASoC: add CSR SiRFSoC audio USP interface driver
This patchset adds the SiRF USP controller driver, this driver uses the USP as I2S or DSP_A mode interface. Rongjun Ying (2): ASoC: sirf: Add audio usp interface driver ASoC: sirf: Add device tree binding for the USP audio device .../devicetree/bindings/sound/sirf-usp.txt | 27 ++ sound/soc/sirf/Kconfig | 6 + sound/soc/sirf/Makefile| 2 + sound/soc/sirf/sirf-usp.c | 415 + sound/soc/sirf/sirf-usp.h | 293 +++ 5 files changed, 743 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/sirf-usp.txt create mode 100644 sound/soc/sirf/sirf-usp.c create mode 100644 sound/soc/sirf/sirf-usp.h -- 1.9.3 Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom More information can be found at www.csr.com. Keep up to date with CSR on our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, www.youtube.com/user/CSRplc, Facebook, www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at www.twitter.com/CSR_plc. New for 2014, you can now access the wide range of products powered by aptX at www.aptx.com. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware loader: inform direct failure when udev loader is disabled
On Wed, Jul 02, 2014 at 09:51:36AM +0800, Ming Lei wrote:
> On Wed, Jul 2, 2014 at 9:01 AM, Luis R. Rodriguez wrote:
> > On Tue, Jul 01, 2014 at 11:22:07AM +0200, Takashi Iwai wrote:
> >> At Tue, 1 Jul 2014 11:54:24 +0800,
> >> Ming Lei wrote:
> >> >
> >> > On Tue, Jul 1, 2014 at 7:30 AM, Luis R. Rodriguez
> >> > wrote:
> >> > > From: "Luis R. Rodriguez"
> >> > >
> >> > > Now that the udev firmware loader is optional request_firmware()
> >> > > will not provide any information on the kernel ring buffer if
> >> > > direct firmware loading failed and udev firmware loading is disabled.
> >> > > If no information is needed request_firmware_direct() should be used
> >> > > for optional firmware, at which point drivers can take on the onus
> >> > > over informing of any failures, if udev firmware loading is disabled
> >> > > though we should at the very least provide some sort of information
> >> > > as when the udev loader was enabled by default back in the days.
> >> > >
> >> > > With this change with a simple firmware load test module [0]:
> >> > >
> >> > > Example output without FW_LOADER_USER_HELPER_FALLBACK
> >> > >
> >> > > platform fake-dev.0: Direct firmware load for fake.bin failed with
> >> > > error -2
> >> > >
> >> > > Example without FW_LOADER_USER_HELPER_FALLBACK
> >> > >
> >> > > platform fake-dev.0: Direct firmware load for fake.bin failed with
> >> > > error -2
> >> > > platform fake-dev.0: Falling back to user helper
> >> > >
> >> > > Without this change without FW_LOADER_USER_HELPER_FALLBACK we get no
> >> > > output
> >> > > logged upon failure.
> >> > >
> >> > > [0] https://github.com/mcgrof/fake-firmware-test.git
> >> > >
> >> > > Cc: Tom Gundersen
> >> > > Cc: Ming Lei
> >> > > Cc: Greg Kroah-Hartman
> >> > > Cc: Abhay Salunke
> >> > > Cc: Stefan Roese
> >> > > Cc: Arnd Bergmann
> >> > > Cc: Kay Sievers
> >> > > Cc: Takashi Iwai
> >> > > Signed-off-by: Luis R. Rodriguez
> >> > > ---
> >> > >
> >> > > drivers/base/firmware_class.c | 12
> >> > > 1 file changed, 8 insertions(+), 4 deletions(-)
> >> > >
> >> > > diff --git a/drivers/base/firmware_class.c
> >> > > b/drivers/base/firmware_class.c
> >> > > index 46ea5f4..23274d8 100644
> >> > > --- a/drivers/base/firmware_class.c
> >> > > +++ b/drivers/base/firmware_class.c
> >> > > @@ -101,8 +101,10 @@ static inline long firmware_loading_timeout(void)
> >> > > #define FW_OPT_NOWAIT (1U << 1)
> >> > > #ifdef CONFIG_FW_LOADER_USER_HELPER
> >> > > #define FW_OPT_USERHELPER (1U << 2)
> >> > > +#define FW_OPT_FAIL_WARN 0
> >> > > #else
> >> > > #define FW_OPT_USERHELPER 0
> >> > > +#define FW_OPT_FAIL_WARN (1U << 3)
> >> > > #endif
> >> > > #ifdef CONFIG_FW_LOADER_USER_HELPER_FALLBACK
> >> > > #define FW_OPT_FALLBACKFW_OPT_USERHELPER
> >> > > @@ -1116,10 +1118,11 @@ _request_firmware(const struct firmware
> >> > > **firmware_p, const char *name,
> >> > >
> >> > > ret = fw_get_filesystem_firmware(device, fw->priv);
> >> > > if (ret) {
> >> > > - if (opt_flags & FW_OPT_USERHELPER) {
> >> > > + if (opt_flags & (FW_OPT_FAIL_WARN | FW_OPT_USERHELPER))
> >> > > dev_warn(device,
> >> > > -"Direct firmware load failed with
> >> > > error %d\n",
> >> > > -ret);
> >> > > +"Direct firmware load for %s failed
> >> > > with error %d\n",
> >> > > +name, ret);
> >> >
> >> > Maybe the warning can be always printed out since
> >> > (FW_OPT_FAIL_WARN | FW_OPT_USERHELPER) should be
> >> > always true.
> >>
> >> Yes, it'd be simpler. Let's reduce lines! :)
> >
> > Actually we don't want to warn when request_firmware_direct() is used
> > right? That's really what
>
> Yes, that is for the CPU microcode update in which it is common to
> fail in direct loading, and x86 guys hate the warning.
I've extended use of request_firmware_direct() to drivers that also load
non-firmware but optional config files, EEPROM override, etc.
> > I meant to upkeep while adding a warning when _direct() is not used. So how
> > about
> > this as an ammendment:
>
> Yes, the idea is right, and it is good to make request_firmware_direct()
> not depend on CONFIG_FW_LOADER_USER_HELPER, and with
> one FW_OPT_DIRECT_ONLY flag together it should work.
OK.
> > diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> > index 23274d8..4f6adf3 100644
> > --- a/drivers/base/firmware_class.c
> > +++ b/drivers/base/firmware_class.c
> > @@ -66,13 +68,12 @@ static inline void release_firmware(const struct
> > firmware *fw)
> > {
> > }
> >
> > -#endif
> > +static inline int request_firmware_direct(const struct firmware **fw,
> > + const char *name,
> > + struct device *device)
> > +{
> > + return -EINVAL;
> > +}
>
> You
Re: [PATCH 2/3] mtd: hisilicon: add a new nand controller driver for hisilicon hip04 Soc
On 2014年06月30日 17:45, Ivan Khoronzhuk wrote: On 06/30/2014 11:03 AM, Zhou Wang wrote: Signed-off-by: Zhou Wang --- drivers/mtd/nand/Kconfig |5 + drivers/mtd/nand/Makefile|1 + drivers/mtd/nand/hisi_nand.c | 847 ++ 3 files changed, 853 insertions(+) create mode 100644 drivers/mtd/nand/hisi_nand.c diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 90ff447..253f8c8 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -510,4 +510,9 @@ config MTD_NAND_XWAY Enables support for NAND Flash chips on Lantiq XWAY SoCs. NAND is attached to the External Bus Unit (EBU). +config MTD_NAND_HISI +tristate "Support for NAND controller on Hisilicon SoC" +help + Enables support for NAND controller on Hisilicon SoC. + endif # MTD_NAND diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index 542b568..d0881cf 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -49,5 +49,6 @@ obj-$(CONFIG_MTD_NAND_JZ4740)+= jz4740_nand.o obj-$(CONFIG_MTD_NAND_GPMI_NAND)+= gpmi-nand/ obj-$(CONFIG_MTD_NAND_XWAY)+= xway_nand.o obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH)+= bcm47xxnflash/ +obj-$(CONFIG_MTD_NAND_HISI)+= hisi_nand.o nand-objs := nand_base.o nand_bbt.o diff --git a/drivers/mtd/nand/hisi_nand.c b/drivers/mtd/nand/hisi_nand.c new file mode 100644 index 000..fbcb065 --- /dev/null +++ b/drivers/mtd/nand/hisi_nand.c @@ -0,0 +1,847 @@ +/* + * Hisilicon NAND Flash controller driver + * + * Copyright © 2012-2014 HiSilicon Technologies Co., Ltd. + * http://www.hisilicon.com + * + * Author: Zhou Wang + * The initial developer of the original code is Zhiyong Cai + * + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define HINFC504_MAX_CHIP (4) +#define HINFC504_W_LATCH(5) +#define HINFC504_R_LATCH(7) +#define HINFC504_RW_LATCH (3) + +#define HINFC504_NFC_TIMEOUT(2 * HZ) +#define HINFC504_NFC_DMA_TIMEOUT(5 * HZ) +#define HINFC504_CHIP_DELAY(25) + +#define HINFC504_REG_BASE_ADDRESS_LEN(0x100) +#define HINFC504_BUFFER_BASE_ADDRESS_LEN(2048 + 128) + +#define HINFC504_ADDR_CYCLE_MASK0x4 + +#define HINFC504_CON0x00 +#define HINFC504_CON_OP_MODE_NORMAL(1U << 0) +#define HINFC504_CON_PAGEISZE_SHIFT(1) +#define HINFC504_CON_PAGESIZE_MASK(0x07) +#define HINFC504_CON_BUS_WIDTH(1U << 4) +#define HINFC504_CON_READY_BUSY_SEL(1U << 8) +#define HINFC504_CON_ECCTYPE_SHIFT(9) +#define HINFC504_CON_ECCTYPE_MASK(0x07) + +#define HINFC504_PWIDTH0x04 +#define SET_HINFC504_PWIDTH(_w_lcnt, _r_lcnt, _rw_hcnt) \ +((_w_lcnt) | (((_r_lcnt) & 0x0F) << 4) | (((_rw_hcnt) & 0x0F) << 8)) + +#define HINFC504_CMD0x0C +#define HINFC504_ADDRL0x10 +#define HINFC504_ADDRH0x14 +#define HINFC504_DATA_NUM0x18 + +#define HINFC504_OP0x1C +#define HINFC504_OP_READ_DATA_EN(1U << 1) +#define HINFC504_OP_WAIT_READY_EN(1U << 2) +#define HINFC504_OP_CMD2_EN(1U << 3) +#define HINFC504_OP_WRITE_DATA_EN(1U << 4) +#define HINFC504_OP_ADDR_EN(1U << 5) +#define HINFC504_OP_CMD1_EN(1U << 6) +#define HINFC504_OP_NF_CS_SHIFT(7) +#define HINFC504_OP_NF_CS_MASK(3) +#define HINFC504_OP_ADDR_CYCLE_SHIFT(9) +#define HINFC504_OP_ADDR_CYCLE_MASK(7) + +#define HINFC504_STATUS0x20 +#define HINFC504_READY(1U << 0) + +#define HINFC504_INTEN0x24 +#define HINFC504_INTEN_DMA(1U << 9) +#define HINFC504_INTEN_UE(1U << 6) +#define HINFC504_INTEN_CE(1U << 5) + +#define HINFC504_INTS0x28 +#define HINFC504_INTS_DMA(1U << 9) +#define HINFC504_INTS_UE(1U << 6) +#define HINFC504_INTS_CE(1U << 5) + +#define HINFC504_INTCLR0x2C +#define
Re: [PATCH 2/3] mtd: hisilicon: add a new nand controller driver for hisilicon hip04 Soc
On 2014年06月30日 17:00, Arnd Bergmann wrote:
Overall a very nice driver. I didn't find any real bugs, but a few things
that could be changed for readability and micro-optimizations:
On Monday 30 June 2014 16:03:28 Zhou Wang wrote:
+#define hinfc_read(_host, _reg)readl(_host->iobase + (_reg))
+#define hinfc_write(_host, _value, _reg)\
+ writel((_value), _host->iobase + (_reg))
I'd recommend making these inline functions rather than macros.
I will change above macros to inline functions, thanks.
+struct hinfc_host {
+ struct nand_chip*chip;
+ struct mtd_info *mtd;
I notice that you allocate the nand_chip and mtd_info together
with the hinfc_host and then assign these pointers. A preferred
method is normally to just embed the structures in this case:
struct hinfc_host {
struct nand_chipchip;
struct mtd_info mtd;
so you avoid the pointer overhead, and can go back from these
two structures to the hinfc_host using container_of().
It is better to embed chip and mtd in host, I will change this, thanks.
+ struct device *dev;
+ void __iomem*iobase;
+ struct completion cmd_complete;
+ unsigned intoffset;
+ unsigned intcommand;
+ int chipselect;
+ unsigned intaddr_cycle;
+ unsigned intaddr_value[2];
+ unsigned intcache_addr_value[2];
+ char*buffer;
+ dma_addr_t dma_buffer;
+ dma_addr_t dma_oob;
+ int version;
+ unsigned intecc_bits;
+ unsigned intirq_status; /* interrupt status */
+
+ int (*send_cmd_pageprog)(struct hinfc_host *host);
+ int (*send_cmd_status)(struct hinfc_host *host);
+ int (*send_cmd_readstart)(struct hinfc_host *host);
+ int (*send_cmd_erase)(struct hinfc_host *host);
+ int (*send_cmd_readid)(struct hinfc_host *host);
+ int (*send_cmd_reset)(struct hinfc_host *host, int chipselect);
+};
Why do you need function pointers here? The current version of the
driver you posted always assigns these to the same functions, so
it would be more efficient to just call those directly.
If you plan to add another variant later that uses a different set
of functions here, you can add the function pointers then, in a
separate patch. Also, a common style element is to have a separate
constant structure with the function pointers:
const struct hinfc_host_ops ops = {
.send_cmd_pageprog = hisi_nfc_send_cmd_pageprog,
...
};
if you actually end up needing function pointers. That simplifies
the code a bit and is slightly more robust to attacks overwriting
the function pointers.
I will move above function pointers out of host and directly call the
functions, thanks for your good comment.
+
+void wait_controller_finished(struct hinfc_host *host)
+{
+ unsigned long timeout = jiffies + HINFC504_NFC_TIMEOUT;
+ int val;
+
+ while (time_before(jiffies, timeout)) {
+ val = hinfc_read(host, HINFC504_STATUS);
+ if (host->command == NAND_CMD_ERASE2) {
+ /* nfc is ready */
+ while (!(val & HINFC504_READY)) {
+ usleep_range(500, 1000);
+ val = hinfc_read(host, HINFC504_STATUS);
+ }
+ return;
+ } else {
+ if (val & HINFC504_READY)
+ return;
+ }
+ }
+
+ /* wait cmd timeout */
+ dev_err(host->dev, "Wait NAND controller exec cmd timeout.\n");
+}
Since the timeout is much bigger than the wait time here, I guess you
can use a wider range for the usleep_range(), e.g.
usleep_range(500, 5);
which is nicer to other tasks. You will normally be woken up much earlier.
Arnd
As I know that the operating time of NAND flash erasure is about
ms-level, so I set sleep time as usleep_range(500, 1000) here. And the
timeout means that relative operations don't finish in this time, so
maybe there is something wrong with the operations. In normal situation,
after detecting the operation finished, the above function will return
before timeout arriving.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: mm: slub: invalid memory access in setup_object
On Tue, Jul 01, 2014 at 02:49:47PM -0700, Andrew Morton wrote:
>On Tue, 1 Jul 2014 09:58:52 -0500 (CDT) Christoph Lameter
>wrote:
>
>> On Mon, 30 Jun 2014, David Rientjes wrote:
>>
>> > It's not at all clear to me that that patch is correct. Wei?
>>
>> Looks ok to me. But I do not like the convoluted code in new_slab() which
>> Wei's patch does not make easier to read. Makes it difficult for the
>> reader to see whats going on.
>>
>> Lets drop the use of the variable named "last".
>>
>>
>> Subject: slub: Only call setup_object once for each object
>>
>> Modify the logic for object initialization to be less convoluted
>> and initialize an object only once.
>>
>
>Well, um. Wei's changelog was much better:
>
>: When a kmem_cache is created with ctor, each object in the kmem_cache will
>: be initialized before use. In the slub implementation, the first object
>: will be initialized twice.
>:
>: This patch avoids the duplication of initialization of the first object.
>:
>: Fixes commit 7656c72b5a63: ("SLUB: add macros for scanning objects in a
>: slab").
>
>I can copy that text over and add the reported-by etc (ho hum) but I
>have a tiny feeling that this patch hasn't been rigorously tested?
>Perhaps someone (Wei?) can do that?
Ok, I will apply this one and give a shot.
>
>And we still don't know why Sasha's kernel went oops.
Yep, if there is some procedure to reproduce it, I'd like to do it at my side.
--
Richard Yang
Help you, Help me
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] staging: comedi: addi_apci_1564: miscellaneous fixes and cleanups
Hi all, On Mon, Jun 30, 2014 at 5:25 AM, Ian Abbott wrote: > On 2014-06-28 05:47, Chase Southwood wrote: >> >> This patchset moves a misplaced include to the proper file, swaps out an >> overly >> aggressive placement of apci1564_reset(), and cleans up >> apci1564_interrupt(). >> >> Chase Southwood (3): >>staging: comedi: addi_apci_1564: move addi_watchdog.h include to >> addi_apci_1564.c >>staging: comedi: addi_apci_1564: fix use of apci1564_reset() to >> disable DI interrupts >>staging: comedi: addi_apci_1564: clean up apci1564_interrupt() >> > > It's okay, but I think you can simplify the interrupt handling a bit more by > not bothering to check for interrupts from unknown sources. If a source > hasn't been enabled, it shouldn't generate interrupts, right? Besides, since > the does nothing to stop further interrupts from unknown sources, it would > just keep getting further interrupts repeatedly in that case. > > Then you can get rid of the ui_DO, ui_DI, ui_Timer, and counters[] variables > and just check the registers directly (e.g. replace 'if (ui_Timer == 1)' > with 'if (inl(devpriv->amcc_iobase + APCI1564_TIMER_IRQ_REG) & 0x01)'). I received some more good comments about the interrupt function, and looks like Greg is on vacation this week anyway, so I think I will just redo patch 3 and send out a v2 patchset. Thanks, Chase -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: mm: slub: invalid memory access in setup_object
On Tue, Jul 01, 2014 at 09:58:52AM -0500, Christoph Lameter wrote:
>On Mon, 30 Jun 2014, David Rientjes wrote:
>
>> It's not at all clear to me that that patch is correct. Wei?
>
>Looks ok to me. But I do not like the convoluted code in new_slab() which
>Wei's patch does not make easier to read. Makes it difficult for the
>reader to see whats going on.
My patch is somewhat convoluted since I wanted to preserve the original logic
and make minimal change. And yes, it looks not that nice to audience.
I feel a little hurt by this patch. What I found and worked is gone with this
patch.
>
>Lets drop the use of the variable named "last".
>
>
>Subject: slub: Only call setup_object once for each object
>
>Modify the logic for object initialization to be less convoluted
>and initialize an object only once.
>
>Signed-off-by: Christoph Lameter
>
>Index: linux/mm/slub.c
>===
>--- linux.orig/mm/slub.c 2014-07-01 09:50:02.486846653 -0500
>+++ linux/mm/slub.c2014-07-01 09:52:07.918802585 -0500
>@@ -1409,7 +1409,6 @@ static struct page *new_slab(struct kmem
> {
> struct page *page;
> void *start;
>- void *last;
> void *p;
> int order;
>
>@@ -1432,15 +1431,11 @@ static struct page *new_slab(struct kmem
> if (unlikely(s->flags & SLAB_POISON))
> memset(start, POISON_INUSE, PAGE_SIZE << order);
>
>- last = start;
> for_each_object(p, s, start, page->objects) {
>- setup_object(s, page, last);
>- set_freepointer(s, last, p);
>- last = p;
>+ setup_object(s, page, p);
>+ set_freepointer(s, p, p + s->size);
> }
>- setup_object(s, page, last);
>- set_freepointer(s, last, NULL);
>-
>+ set_freepointer(s, start + (page->objects - 1) * s->size, NULL);
> page->freelist = start;
> page->inuse = page->objects;
> page->frozen = 1;
--
Richard Yang
Help you, Help me
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/14] cpufreq: cpu0: OPPs can be populated at runtime
On 1 July 2014 23:32, Stephen Boyd wrote: > Please update the binding as well to indicate that this property is now > optional. Does this look fine.. diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt index f055515..366690c 100644 --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt @@ -8,10 +8,12 @@ Both required and optional properties listed below must be defined under node /cpus/cpu@0. Required properties: -- operating-points: Refer to Documentation/devicetree/bindings/power/opp.txt - for details +- None Optional properties: +- operating-points: Refer to Documentation/devicetree/bindings/power/opp.txt for + details. OPPs *must* be supplied either via DT, i.e. this property, or + populated at runtime. - clock-latency: Specify the possible maximum transition latency for clock, in unit of nanoseconds. - voltage-tolerance: Specify the CPU voltage tolerance in percentage. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/14] clk: Create of_clk_shared_by_cpus()
On 1 July 2014 23:30, Stephen Boyd wrote: > On 07/01/14 09:32, Viresh Kumar wrote: >> Create a new routine of_clk_shared_by_cpus() that finds if clock lines are >> shared between two CPUs. This is verified by comparing "clocks" property from >> CPU's DT node. >> >> Returns 1 if clock line is shared between them, 0 if clock isn't shared and >> return appropriate errors in case nodes/properties are missing. >> >> Cc: Mike Turquette >> Signed-off-by: Viresh Kumar >> --- >> drivers/clk/clk.c | 56 >> + >> include/linux/clk.h | 6 ++ > > This doesn't make much sense to me. This function doesn't deal with > struct clk pointers or any of the internals of the common clock > framework so why put it in clk.c? It looks more like an internal > function that the cpufreq-generic driver should have. I thought this is what Rob suggested when he said: "I think a clock api function would be better." I had it in cpufreq-cpu0 driver earlier and moved it to a separate API yesterday only. Sorry if I misunderstood his comment. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Confidential Email-v
Dear Friend, I am Mr. Juan Morato, the Auditor General of Unicaja Bank Madrid. In the course of my auditing, I discovered a floating fund in an account, which was opened in 1990 at Cam Bank before it was bought over by Unicaja Group which I am the auditor belonging to a dead foreigner Mr. Kenny who died in 2004. Every effort made to track any member of his family or next of kin has since failed; hence I got in contact with you to stand as his next of kin since you bear the same last name. He died leaving no heir or a will. My intention is to transfer this sum of 5.5M in the aforementioned account to a safe account. I am therefore proposing that you quietly partner with me and provide an account or set up a new one that will serve the purpose of receiving this fund. For your assistance in this venture, I am ready to part with a good percentage of the entire funds. After going through the deceased person's records and files, I discovered that: (1) No one has operated this account since 2004 (2) He died without an heir; hence the money has been floating. (3) No other person knows about this account and there was no known beneficiary. If I do not remit this money urgently, it would be forfeited and subsequently converted to company's funds, which will benefit only the directors of my firm. This money can be approved to you legally as with all the necessary documentary approvals in your name. However, you would be required to show some proof of claim, which I will provide you with and also guide you on how to make your applications. Please do give me a reply on my private e-mail juan.mora...@1email.eu or fax 00 34 917 692 656 so that I can send you detailed information on the modalities of my proposition. I completely trust you to keep this proposition absolutely confidential. Kindly forward your telephone number where I can reach you easily. I look forward to your prompt response. Best Regards, Mr. Juan Morato Tel: 00 34 634 031 280 Fax: 00 34 917 692 656 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] firmware loader: inform direct failure when udev loader is disabled
On Wed, Jul 2, 2014 at 9:01 AM, Luis R. Rodriguez wrote:
> On Tue, Jul 01, 2014 at 11:22:07AM +0200, Takashi Iwai wrote:
>> At Tue, 1 Jul 2014 11:54:24 +0800,
>> Ming Lei wrote:
>> >
>> > On Tue, Jul 1, 2014 at 7:30 AM, Luis R. Rodriguez
>> > wrote:
>> > > From: "Luis R. Rodriguez"
>> > >
>> > > Now that the udev firmware loader is optional request_firmware()
>> > > will not provide any information on the kernel ring buffer if
>> > > direct firmware loading failed and udev firmware loading is disabled.
>> > > If no information is needed request_firmware_direct() should be used
>> > > for optional firmware, at which point drivers can take on the onus
>> > > over informing of any failures, if udev firmware loading is disabled
>> > > though we should at the very least provide some sort of information
>> > > as when the udev loader was enabled by default back in the days.
>> > >
>> > > With this change with a simple firmware load test module [0]:
>> > >
>> > > Example output without FW_LOADER_USER_HELPER_FALLBACK
>> > >
>> > > platform fake-dev.0: Direct firmware load for fake.bin failed with error
>> > > -2
>> > >
>> > > Example without FW_LOADER_USER_HELPER_FALLBACK
>> > >
>> > > platform fake-dev.0: Direct firmware load for fake.bin failed with error
>> > > -2
>> > > platform fake-dev.0: Falling back to user helper
>> > >
>> > > Without this change without FW_LOADER_USER_HELPER_FALLBACK we get no
>> > > output
>> > > logged upon failure.
>> > >
>> > > [0] https://github.com/mcgrof/fake-firmware-test.git
>> > >
>> > > Cc: Tom Gundersen
>> > > Cc: Ming Lei
>> > > Cc: Greg Kroah-Hartman
>> > > Cc: Abhay Salunke
>> > > Cc: Stefan Roese
>> > > Cc: Arnd Bergmann
>> > > Cc: Kay Sievers
>> > > Cc: Takashi Iwai
>> > > Signed-off-by: Luis R. Rodriguez
>> > > ---
>> > >
>> > > drivers/base/firmware_class.c | 12
>> > > 1 file changed, 8 insertions(+), 4 deletions(-)
>> > >
>> > > diff --git a/drivers/base/firmware_class.c
>> > > b/drivers/base/firmware_class.c
>> > > index 46ea5f4..23274d8 100644
>> > > --- a/drivers/base/firmware_class.c
>> > > +++ b/drivers/base/firmware_class.c
>> > > @@ -101,8 +101,10 @@ static inline long firmware_loading_timeout(void)
>> > > #define FW_OPT_NOWAIT (1U << 1)
>> > > #ifdef CONFIG_FW_LOADER_USER_HELPER
>> > > #define FW_OPT_USERHELPER (1U << 2)
>> > > +#define FW_OPT_FAIL_WARN 0
>> > > #else
>> > > #define FW_OPT_USERHELPER 0
>> > > +#define FW_OPT_FAIL_WARN (1U << 3)
>> > > #endif
>> > > #ifdef CONFIG_FW_LOADER_USER_HELPER_FALLBACK
>> > > #define FW_OPT_FALLBACKFW_OPT_USERHELPER
>> > > @@ -1116,10 +1118,11 @@ _request_firmware(const struct firmware
>> > > **firmware_p, const char *name,
>> > >
>> > > ret = fw_get_filesystem_firmware(device, fw->priv);
>> > > if (ret) {
>> > > - if (opt_flags & FW_OPT_USERHELPER) {
>> > > + if (opt_flags & (FW_OPT_FAIL_WARN | FW_OPT_USERHELPER))
>> > > dev_warn(device,
>> > > -"Direct firmware load failed with error
>> > > %d\n",
>> > > -ret);
>> > > +"Direct firmware load for %s failed
>> > > with error %d\n",
>> > > +name, ret);
>> >
>> > Maybe the warning can be always printed out since
>> > (FW_OPT_FAIL_WARN | FW_OPT_USERHELPER) should be
>> > always true.
>>
>> Yes, it'd be simpler. Let's reduce lines! :)
>
> Actually we don't want to warn when request_firmware_direct() is used right?
> That's really what
Yes, that is for the CPU microcode update in which it is common to
fail in direct loading, and x86 guys hate the warning.
> I meant to upkeep while adding a warning when _direct() is not used. So how
> about
> this as an ammendment:
Yes, the idea is right, and it is good to make request_firmware_direct()
not depend on CONFIG_FW_LOADER_USER_HELPER, and with
one FW_OPT_DIRECT_ONLY flag together it should work.
>
> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> index 23274d8..4f6adf3 100644
> --- a/drivers/base/firmware_class.c
> +++ b/drivers/base/firmware_class.c
> @@ -1180,7 +1180,6 @@ request_firmware(const struct firmware **firmware_p,
> const char *name,
> }
> EXPORT_SYMBOL(request_firmware);
>
> -#ifdef CONFIG_FW_LOADER_USER_HELPER_FALLBACK
> /**
> * request_firmware: - load firmware directly without usermode helper
> * @firmware_p: pointer to firmware image
> @@ -1202,7 +1201,6 @@ int request_firmware_direct(const struct firmware
> **firmware_p,
> return ret;
> }
> EXPORT_SYMBOL_GPL(request_firmware_direct);
> -#endif
>
> /**
> * release_firmware: - release the resource associated with a firmware image
> diff --git a/include/linux/firmware.h b/include/linux/firmware.h
> index 67e5b80..5c41c5e 100644
> --- a/include/linux/firmware.h
> +++ b/include/linux/firmware.h
> @@ -45,6 +45,8 @@ int
Re: mm: shm: hang in shmem_fallocate
On Tue, 1 Jul 2014, Vlastimil Babka wrote: > On 06/27/2014 07:36 AM, Hugh Dickins wrote:> [Cc Johannes: at the end I have > a particular question for you] > > On Thu, 26 Jun 2014, Vlastimil Babka wrote: > > > > > > Thanks, I didn't notice that. Do I understand correctly that this could > > > mean > > > info leak for the punch hole call, but wouldn't be a problem for madvise? > > > (In > > > any case, that means the solution is not general enough for all kernels, > > > so > > > I'm asking just to be sure). > > > > It's exactly the same issue for the madvise as for the fallocate: > > data that is promised to have been punched out would still be there. > > AFAIK madvise doesn't promise anything. But nevermind. Good point. I was looking at it from an implementation point of view, that the implementation is the same for both, so therefore the same issue for both. But you are right, madvise makes no promise, so we can therefore excuse it. You'd make a fine lawyer :) > > > > So let's all forget that patch, although it does help to highlight my > > mistake in d0823576bf4b. (Oh, hey, let's all forget my mistake too!) > > What patch? What mistake? :) Yes, which of my increasingly many? :( > > > Here's the 3.16-rc2 patch that I've now settled on (which will also > > require a revert of current git's f00cdc6df7d7; well, not require the > > revert, but this makes that redundant, and cannot be tested with it in). > > > > I've not yet had time to write up the patch description, nor to test > > it fully; but thought I should get the patch itself into the open for > > review and testing before then. > > It seems to work here (tested 3.16-rc1 which didn't have f00cdc6df7d7 yet). > Checking for end != -1 is indeed much more elegant solution than i_size. > Thanks. So you can add my Tested-by. Thanks a lot for the testing, Vlastimir. Though I'm happy with the new shmem.c patch, I've thought more about my truncate.c patch meanwhile, and grown unhappy with it for two reasons. One was remembering that XFS still uses lend -1 even when punching a hole: it writes out dirty pages, then throws away the pagecache from start of hole to end of file; not brilliant (and a violation of mlock), but that's how it is, and I'm not about to become an XFS hacker to fix it (I did long ago send a patch I thought fixed it, but it never went in, and I could easily have overlooked all kinds of XFS subtleties). So although the end -1 test is more satisfying in tmpfs, and I don't particularly like making assumptions in truncate_inode_pages_range() about what i_size will show at that point, XFS would probably push me back to using your original i_size test in truncate.c. If we are to stop the endless pincer in truncate.c like in shmem.c. But the other reason I'm unhappy with it, is really a generalization of that. Starting from the question I asked Hannes below, I came to realize that truncate_inode_pages_range() is serving many filesystems, and I don't know what all their assumptions are; and even if I spent days researching what each requires of truncate_inode_pages_range(), chances are that I wouldn't get the right answer on all of them. Maybe there is a filesystem which now depends upon it to clean out that hole completely: obviously not before I made the change, but perhaps in the years since. So, although I dislike tmpfs behaviour diverging from the others here, we do have Sasha's assurance that tmpfs was the only one to show the problem, and no intention of implementing hole-punch on ramfs: so I think the safest course is for me not to interfere with the other filesystems, just fix the pessimization I introduced back then. And now that we have hard evidence that my "fix" there in -rc3 must be reverted, I should move forward with the alternative. Hugh > > > I've checked against v3.1 to see how it works out there: certainly > > wouldn't apply cleanly (and beware: prior to v3.5's shmem_undo_range, > > "end" was included in the range, not excluded), but the same > > principles apply. Haven't checked the intermediates yet, will > > probably leave those until each stable wants them - but if you've a > > particular release in mind, please ask, or ask me to check your port. > > I will try, thanks. > > > I've included the mm/truncate.c part of it here, but that will be a > > separate (not for -stable) patch when I post the finalized version. > > > > Hannes, a question for you please, I just could not make up my mind. > > In mm/truncate.c truncate_inode_pages_range(), what should be done > > with a failed clear_exceptional_entry() in the case of hole-punch? > > Is that case currently depending on the rescan loop (that I'm about > > to revert) to remove a new page, so I would need to add a retry for > > that rather like the shmem_free_swap() one? Or is it irrelevant, > > and can stay unchanged as below? I've veered back and forth, > > thinking first one and then the other. > > > > Thanks, > > Hugh > > > > --- > > > >
Re: [PATCH v2 1/1] firmware: read firmware size using i_size_read()
On Thu, Jun 26, 2014 at 12:46 AM, Dmitry Kasatkin wrote: > On 13 June 2014 19:06, Dmitry Kasatkin wrote: >> On 13 June 2014 19:03, Ming Lei wrote: >>> On Fri, Jun 13, 2014 at 11:09 PM, Dmitry Kasatkin >>> wrote: There is no need to read attr because inode structure contains size of the file. Use i_size_read() instead. Signed-off-by: Dmitry Kasatkin >>> >>> Acked-by: Ming Lei >>> > > > Hi, > > BTW. To what tree it is applied? Greg will take it in driver-core tree. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] SCHED: remove proliferation of wait_on_bit action functions.
On Fri, 6 Jun 2014 08:04:19 +0200 Ingo Molnar wrote:
>
> * NeilBrown wrote:
>
> > On Thu, 5 Jun 2014 14:45:09 +0200 Ingo Molnar wrote:
> >
> > >
> > > * NeilBrown wrote:
> > >
> > > > On Thu, 22 May 2014 11:05:02 +0200 Ingo Molnar wrote:
> > > >
> > > > >
> > > > > * NeilBrown wrote:
> > > > >
> > > > > > [[ get_maintainer.pl suggested 61 email address for this patch.
> > > > > >I've trimmed that list somewhat. Hope I didn't miss anyone
> > > > > >important...
> > > > > >I'm hoping it will go in through the scheduler tree, but would
> > > > > >particularly like an Acked-by for the fscache parts. Other acks
> > > > > >welcome.
> > > > > > ]]
> > > > > >
> > > > > > The current "wait_on_bit" interface requires an 'action' function
> > > > > > to be provided which does the actual waiting.
> > > > > > There are over 20 such functions, many of them identical.
> > > > > > Most cases can be satisfied by one of just two functions, one
> > > > > > which uses io_schedule() and one which just uses schedule().
> > > > > >
> > > > > > So:
> > > > > > Rename wait_on_bit andwait_on_bit_lock to
> > > > > > wait_on_bit_action and wait_on_bit_lock_action
> > > > > > to make it explicit that they need an action function.
> > > > > >
> > > > > > Introduce new wait_on_bit{,_lock} and wait_on_bit{,_lock}_io
> > > > > > which are *not* given an action function but implicitly use
> > > > > > a standard one.
> > > > > > The decision to error-out if a signal is pending is now made
> > > > > > based on the 'mode' argument rather than being encoded in the
> > > > > > action
> > > > > > function.
> > > > >
> > > > > this patch fails to build on x86-32 allyesconfigs.
> > > >
> > > > Could you share the build errors?
> > >
> > > Sure, find it attached below.
> >
> > Thanks.
> >
> > It looks like this is a wait_on_bit usage that was added after I created the
> > patch.
> >
> > How about you drop my patch for now, we wait for -rc1 to come out, then I
> > submit a new version against -rc1 and we get that into -rc2.
> > That should minimise such conflicts.
> >
> > Does that work for you?
>
> Sure, that sounds like a good approach, if Linus doesn't object.
>
Hi Ingo,
I re-posted these patches based on -rc2 (I missed -rc1, it was too fast) and
have not heard anything over a week later. Did I misunderstand? Did you
want me to send them direct to Linus?
Or are you on a summer break and I should just be patient?
Thanks,
NeilBrown
signature.asc
Description: PGP signature
linux-next: manual merge of the arm-perf tree with the arm tree
Hi Will,
Today's linux-next merge of the arm-perf tree got a conflict in
arch/arm/kernel/perf_event_cpu.c between commit 324bbc0804ac ("ARM:
make it easier to check the CPU part number correctly") from the arm
tree and commit 6f73e8ababdd ("arm: perf: clean up PMU names") from the
arm-perf tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/kernel/perf_event_cpu.c
index c02c2e8c877d,c63dc4201a7f..
--- a/arch/arm/kernel/perf_event_cpu.c
+++ b/arch/arm/kernel/perf_event_cpu.c
@@@ -254,35 -259,38 +257,39 @@@ static int probe_current_pmu(struct arm
pr_info("probing PMU on CPU %d\n", cpu);
+ switch (read_cpuid_part()) {
/* ARM Ltd CPUs. */
- if (implementor == ARM_CPU_IMP_ARM) {
- switch (part_number) {
- case ARM_CPU_PART_ARM1136:
- ret = armv6_1136_pmu_init(pmu);
- break;
- case ARM_CPU_PART_ARM1156:
- ret = armv6_1156_pmu_init(pmu);
- break;
- case ARM_CPU_PART_ARM1176:
- ret = armv6_1176_pmu_init(pmu);
- break;
- case ARM_CPU_PART_ARM11MPCORE:
- ret = armv6mpcore_pmu_init(pmu);
- break;
- case ARM_CPU_PART_CORTEX_A8:
- ret = armv7_a8_pmu_init(pmu);
- break;
- case ARM_CPU_PART_CORTEX_A9:
- ret = armv7_a9_pmu_init(pmu);
- break;
- }
- /* Intel CPUs [xscale]. */
- } else if (implementor == ARM_CPU_IMP_INTEL) {
- switch (xscale_cpu_arch_version()) {
- case ARM_CPU_XSCALE_ARCH_V1:
- ret = xscale1pmu_init(pmu);
- break;
- case ARM_CPU_XSCALE_ARCH_V2:
- ret = xscale2pmu_init(pmu);
- break;
+ case ARM_CPU_PART_ARM1136:
++ ret = armv6_1136_pmu_init(pmu);
++ break;
+ case ARM_CPU_PART_ARM1156:
++ ret = armv6_1156_pmu_init(pmu);
++ break;
+ case ARM_CPU_PART_ARM1176:
- ret = armv6pmu_init(pmu);
++ ret = armv6_1176_pmu_init(pmu);
+ break;
+ case ARM_CPU_PART_ARM11MPCORE:
+ ret = armv6mpcore_pmu_init(pmu);
+ break;
+ case ARM_CPU_PART_CORTEX_A8:
+ ret = armv7_a8_pmu_init(pmu);
+ break;
+ case ARM_CPU_PART_CORTEX_A9:
+ ret = armv7_a9_pmu_init(pmu);
+ break;
+
+ default:
+ if (read_cpuid_implementor() == ARM_CPU_IMP_INTEL) {
+ switch (xscale_cpu_arch_version()) {
+ case ARM_CPU_XSCALE_ARCH_V1:
+ ret = xscale1pmu_init(pmu);
+ break;
+ case ARM_CPU_XSCALE_ARCH_V2:
+ ret = xscale2pmu_init(pmu);
+ break;
+ }
}
+ break;
}
put_cpu();
signature.asc
Description: PGP signature
Re: [PATCH v2] perf/x86/intel: ignore CondChgd bit to avoid false NMI handling
From: Andi Kleen Subject: Re: [PATCH v2] perf/x86/intel: ignore CondChgd bit to avoid false NMI handling Date: Mon, 30 Jun 2014 15:22:24 -0700 >> >> I'm also interested in the behaviour of CondChgd bit on Ivy Bridge >> processors. > > The intended meaning of CondChgd is that a hardware debugger has taken over > the > PMU. It shouldn't really be set in other circumstances. > Thanks for your explanation. The hardware debugger you mean is a kind of ITP? > I think right now for perf it would be best to just ignore it. > > In theory could stop using the PMU, but if some BIOS set it it would > completely disable perf there. So better to just ignore it. > I'll reflect this information in the patch description. -- Thanks. HATAYAMA, Daisuke -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ASoC: add driver for Rockchip RK3xxx I2S controller
Hi, Mark:
于 2014年07月02日 01:07, Mark Brown 写道:
>> +static inline void i2s_writel(struct rk_i2s_dev *i2s, u32 value,
>> > +unsigned int offset)
>> > +{
>> > + writel_relaxed(value, i2s->regs + offset);
>> > +}
>> > +
>> > +static inline u32 i2s_readl(struct rk_i2s_dev *i2s, unsigned int offset)
>> > +{
>> > + return readl_relaxed(i2s->regs + offset);
>> > +}
> Perhaps use regmap? The main advantage would be the debug
> infrastructure, though you could also use _update_bits() to reduce the
> amount of time spent locked.
>
Are you sure? This is a I2S driver, we can write the register directly,
do not through I2C or SPI bus.
Write a register is only a few instructions on ARM, but write through
regmap, it may take a long path.
I think it will just consume CPU power and make the whole thing more
complex.
Could you tell me what benefits we can get if use regmap? Or something I
just missing?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 07/12] usb: chipidea: add a generic driver
> > Hello. > > On 07/01/2014 02:42 PM, Alexandre Belloni wrote: > > > Well, there is nothing specific about the Berlin CI. Some > > subsystems use the 'generic' keyword in these cases. Do you see a > > particular reason I should use some Berlin related compatible here? > > Not must, one suggestion is: can you change the compatible string > to "chipidea-usb-generic"? > > >>> I don't know about ChipIdea/ARC/DW's product portfolio but I guess > >>> the compatible should also carry '2.0' or 'usb2' in it. Or we just > >>> use some version number like 'chipidea,ci13000' or 'chipidea,ci13xxx'. > > >> The recommended format for compatible string is: > >> "manufacturer,model", I agree with "chipidea,ci13xxx", thanks. > > > I think we should probably avoid using wildcards in the compatible > > string. > > I'm sure wildcards shouldn't be allowed there. :-) Then, what's your guys recommend, how about "chipidea,usb2-generic"? Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH] dup3(): option to detect close() error
The RFC patch below adds a new flag for dup3().
(For simplicity, I'm just reusing O_EXCL for now.)
I am assuming calling f_op->flush() twice instead of just once
before closing the file is not harmful.
The idea is to extend dup3() so that we can catch close() errors
for the descriptor to be replaced, if we want to. Existing code
will not see any changes. (Userspace might wish to replace a
descriptor exactly because there is a problem, so we don't want
to make this unconditional.
This approach relies on close() having a single error path in Linux:
the file has an f_op->flush() handler, and it returns an error.
Here, if the flag is included in dup3(), f_op->flush() is called early
for newfd, and if it fails, dup3() will return with -EIO.
It will still be called again in filp_close(), but since the descriptor
is to be closed, there should be no activity between the two
f_op->flush() calls, so the latter should not fail.
Is there a reason (besides having yet another O_ flag) why this
would not work, or why we would not want to do this?
Am I missing something?
I just want be able to know if a problem was detected, that's all.
Best,
Nominal Animal
diff -u5 -bar linux-3.16-rc3/fs/file.c linux-3.16-rc3.new/fs/file.c
--- linux-3.16-rc3/fs/file.c2014-06-30 00:11:36.0 +0300
+++ linux-3.16-rc3.new/fs/file.c2014-07-02 02:04:23.708114821 +0300
@@ -816,21 +816,31 @@
SYSCALL_DEFINE3(dup3, unsigned int, oldfd, unsigned int, newfd, int, flags)
{
int err = -EBADF;
- struct file *file;
+ struct file *file, *tofree;
struct files_struct *files = current->files;
- if ((flags & ~O_CLOEXEC) != 0)
+ if ((flags & ~(O_CLOEXEC | O_EXCL)) != 0)
return -EINVAL;
if (unlikely(oldfd == newfd))
return -EINVAL;
if (newfd >= rlimit(RLIMIT_NOFILE))
return -EBADF;
spin_lock(>file_lock);
+ if (unlikely(flags & O_EXCL)) {
+ tofree = fcheck(newfd);
+ if (tofree && file_count(tofree) && tofree->f_op->flush) {
+ spin_unlock(>file_lock);
+ err = tofree->f_op->flush(tofree, files);
+ if (unlikely(err < 0))
+ return -EIO;
+ spin_lock(>file_lock);
+ }
+ }
err = expand_files(files, newfd);
file = fcheck(oldfd);
if (unlikely(!file))
goto Ebadf;
if (unlikely(err < 0)) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5] USB: ehci-pci: USB host controller support for Intel Quark X1000
From: Bryan O'Donoghue
The EHCI packet buffer in/out threshold is programmable for Intel Quark X1000
USB host controller, and the default value is 0x20 dwords. The in/out threshold
can be programmed to 0x80 dwords (512 Bytes) to maximize the perfomrance,
but only when isochronous/interrupt transactions are not initiated by the USB
host controller. This patch is to reconfigure the packet buffer in/out
threshold as maximal as possible to maximize the performance, and 0x7F dwords
(508 Bytes) should be used because the USB host controller initiates
isochronous/interrupt transactions.
Signed-off-by: Bryan O'Donoghue
Signed-off-by: Alvin (Weike) Chen
Acked-by: Alan Stern
Reviewed-by: Jingoo Han
---
Changlog v5:
* Correct the wrong comment style.
drivers/usb/host/ehci-pci.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 3e86bf4..ca7b964 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -35,6 +35,21 @@ static const char hcd_name[] = "ehci-pci";
#define PCI_DEVICE_ID_INTEL_CE4100_USB 0x2e70
/*-*/
+#define PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC0x0939
+static inline bool is_intel_quark_x1000(struct pci_dev *pdev)
+{
+ return pdev->vendor == PCI_VENDOR_ID_INTEL &&
+ pdev->device == PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC;
+}
+
+/*
+ * 0x84 is the offset of in/out threshold register,
+ * and it is the same offset as the register of 'hostpc'.
+ */
+#defineintel_quark_x1000_insnreg01 hostpc
+
+/* Maximum usable threshold value is 0x7f dwords for both IN and OUT */
+#define INTEL_QUARK_X1000_EHCI_MAX_THRESHOLD 0x007f007f
/* called after powerup, by probe or system-pm "wakeup" */
static int ehci_pci_reinit(struct ehci_hcd *ehci, struct pci_dev *pdev)
@@ -50,6 +65,16 @@ static int ehci_pci_reinit(struct ehci_hcd *ehci, struct
pci_dev *pdev)
if (!retval)
ehci_dbg(ehci, "MWI active\n");
+ /* Reset the threshold limit */
+ if (is_intel_quark_x1000(pdev)) {
+ /*
+* For the Intel QUARK X1000, raise the I/O threshold to the
+* maximum usable value in order to improve performance.
+*/
+ ehci_writel(ehci, INTEL_QUARK_X1000_EHCI_MAX_THRESHOLD,
+ ehci->regs->intel_quark_x1000_insnreg01);
+ }
+
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware loader: inform direct failure when udev loader is disabled
On Tue, Jul 01, 2014 at 11:22:07AM +0200, Takashi Iwai wrote:
> At Tue, 1 Jul 2014 11:54:24 +0800,
> Ming Lei wrote:
> >
> > On Tue, Jul 1, 2014 at 7:30 AM, Luis R. Rodriguez
> > wrote:
> > > From: "Luis R. Rodriguez"
> > >
> > > Now that the udev firmware loader is optional request_firmware()
> > > will not provide any information on the kernel ring buffer if
> > > direct firmware loading failed and udev firmware loading is disabled.
> > > If no information is needed request_firmware_direct() should be used
> > > for optional firmware, at which point drivers can take on the onus
> > > over informing of any failures, if udev firmware loading is disabled
> > > though we should at the very least provide some sort of information
> > > as when the udev loader was enabled by default back in the days.
> > >
> > > With this change with a simple firmware load test module [0]:
> > >
> > > Example output without FW_LOADER_USER_HELPER_FALLBACK
> > >
> > > platform fake-dev.0: Direct firmware load for fake.bin failed with error
> > > -2
> > >
> > > Example without FW_LOADER_USER_HELPER_FALLBACK
> > >
> > > platform fake-dev.0: Direct firmware load for fake.bin failed with error
> > > -2
> > > platform fake-dev.0: Falling back to user helper
> > >
> > > Without this change without FW_LOADER_USER_HELPER_FALLBACK we get no
> > > output
> > > logged upon failure.
> > >
> > > [0] https://github.com/mcgrof/fake-firmware-test.git
> > >
> > > Cc: Tom Gundersen
> > > Cc: Ming Lei
> > > Cc: Greg Kroah-Hartman
> > > Cc: Abhay Salunke
> > > Cc: Stefan Roese
> > > Cc: Arnd Bergmann
> > > Cc: Kay Sievers
> > > Cc: Takashi Iwai
> > > Signed-off-by: Luis R. Rodriguez
> > > ---
> > >
> > > drivers/base/firmware_class.c | 12
> > > 1 file changed, 8 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> > > index 46ea5f4..23274d8 100644
> > > --- a/drivers/base/firmware_class.c
> > > +++ b/drivers/base/firmware_class.c
> > > @@ -101,8 +101,10 @@ static inline long firmware_loading_timeout(void)
> > > #define FW_OPT_NOWAIT (1U << 1)
> > > #ifdef CONFIG_FW_LOADER_USER_HELPER
> > > #define FW_OPT_USERHELPER (1U << 2)
> > > +#define FW_OPT_FAIL_WARN 0
> > > #else
> > > #define FW_OPT_USERHELPER 0
> > > +#define FW_OPT_FAIL_WARN (1U << 3)
> > > #endif
> > > #ifdef CONFIG_FW_LOADER_USER_HELPER_FALLBACK
> > > #define FW_OPT_FALLBACKFW_OPT_USERHELPER
> > > @@ -1116,10 +1118,11 @@ _request_firmware(const struct firmware
> > > **firmware_p, const char *name,
> > >
> > > ret = fw_get_filesystem_firmware(device, fw->priv);
> > > if (ret) {
> > > - if (opt_flags & FW_OPT_USERHELPER) {
> > > + if (opt_flags & (FW_OPT_FAIL_WARN | FW_OPT_USERHELPER))
> > > dev_warn(device,
> > > -"Direct firmware load failed with error
> > > %d\n",
> > > -ret);
> > > +"Direct firmware load for %s failed with
> > > error %d\n",
> > > +name, ret);
> >
> > Maybe the warning can be always printed out since
> > (FW_OPT_FAIL_WARN | FW_OPT_USERHELPER) should be
> > always true.
>
> Yes, it'd be simpler. Let's reduce lines! :)
Actually we don't want to warn when request_firmware_direct() is used right?
That's really what
I meant to upkeep while adding a warning when _direct() is not used. So how
about
this as an ammendment:
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 23274d8..4f6adf3 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -1180,7 +1180,6 @@ request_firmware(const struct firmware **firmware_p,
const char *name,
}
EXPORT_SYMBOL(request_firmware);
-#ifdef CONFIG_FW_LOADER_USER_HELPER_FALLBACK
/**
* request_firmware: - load firmware directly without usermode helper
* @firmware_p: pointer to firmware image
@@ -1202,7 +1201,6 @@ int request_firmware_direct(const struct firmware
**firmware_p,
return ret;
}
EXPORT_SYMBOL_GPL(request_firmware_direct);
-#endif
/**
* release_firmware: - release the resource associated with a firmware image
diff --git a/include/linux/firmware.h b/include/linux/firmware.h
index 67e5b80..5c41c5e 100644
--- a/include/linux/firmware.h
+++ b/include/linux/firmware.h
@@ -45,6 +45,8 @@ int request_firmware_nowait(
struct module *module, bool uevent,
const char *name, struct device *device, gfp_t gfp, void *context,
void (*cont)(const struct firmware *fw, void *context));
+int request_firmware_direct(const struct firmware **fw, const char *name,
+ struct device *device);
void release_firmware(const struct firmware *fw);
#else
@@ -66,13 +68,12 @@ static inline void release_firmware(const struct firmware
*fw)
{
}
-#endif
+static inline int
Re: [PATCH v3 5/9] slab: introduce alien_cache
On Tue, Jul 01, 2014 at 03:15:47PM -0700, Andrew Morton wrote:
> On Tue, 1 Jul 2014 17:27:34 +0900 Joonsoo Kim wrote:
>
> > -static struct array_cache **alloc_alien_cache(int node, int limit, gfp_t
> > gfp)
> > +static struct alien_cache *__alloc_alien_cache(int node, int entries,
> > + int batch, gfp_t gfp)
> > +{
> > + int memsize = sizeof(void *) * entries + sizeof(struct alien_cache);
>
> nit: all five memsizes in slab.c have type `int'. size_t would be more
> appropriate.
>
Hello,
As my inspection, there are 4 memsize. Can you confirm that?
Anyway, here goes the patch you suggested.
Thanks.
--8<-
>From e9ae011804f3d90375b2e50c0dbd95e708afc509 Mon Sep 17 00:00:00 2001
From: Joonsoo Kim
Date: Wed, 2 Jul 2014 09:23:05 +0900
Subject: [PATCH] slab: change int to size_t for representing allocation size
It is better to represent allocation size in size_t rather than int.
So change it.
Suggested-by: Andrew Morton
Signed-off-by: Joonsoo Kim
diff --git a/mm/slab.c b/mm/slab.c
index 5b0224c..e7763db 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -681,7 +681,7 @@ static void init_arraycache(struct array_cache *ac, int
limit, int batch)
static struct array_cache *alloc_arraycache(int node, int entries,
int batchcount, gfp_t gfp)
{
- int memsize = sizeof(void *) * entries + sizeof(struct array_cache);
+ size_t memsize = sizeof(void *) * entries + sizeof(struct array_cache);
struct array_cache *ac = NULL;
ac = kmalloc_node(memsize, gfp, node);
@@ -868,7 +868,7 @@ static void *alternate_node_alloc(struct kmem_cache *,
gfp_t);
static struct alien_cache *__alloc_alien_cache(int node, int entries,
int batch, gfp_t gfp)
{
- int memsize = sizeof(void *) * entries + sizeof(struct alien_cache);
+ size_t memsize = sizeof(void *) * entries + sizeof(struct alien_cache);
struct alien_cache *alc = NULL;
alc = kmalloc_node(memsize, gfp, node);
@@ -880,7 +880,7 @@ static struct alien_cache *__alloc_alien_cache(int node,
int entries,
static struct alien_cache **alloc_alien_cache(int node, int limit, gfp_t gfp)
{
struct alien_cache **alc_ptr;
- int memsize = sizeof(void *) * nr_node_ids;
+ size_t memsize = sizeof(void *) * nr_node_ids;
int i;
if (limit > 1)
@@ -1037,7 +1037,7 @@ static int init_cache_node_node(int node)
{
struct kmem_cache *cachep;
struct kmem_cache_node *n;
- const int memsize = sizeof(struct kmem_cache_node);
+ const size_t memsize = sizeof(struct kmem_cache_node);
list_for_each_entry(cachep, _caches, list) {
/*
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 4/9] slab: factor out initialization of arracy cache
On Tue, Jul 01, 2014 at 03:26:26PM -0700, David Rientjes wrote:
> On Tue, 1 Jul 2014, Joonsoo Kim wrote:
>
> > Factor out initialization of array cache to use it in following patch.
> >
> > Acked-by: Christoph Lameter
> > Signed-off-by: Joonsoo Kim
>
> Not sure what happened to my
>
> Acked-by: David Rientjes
>
> from http://marc.info/?l=linux-mm=139951195724487 and my comment still
> stands about s/arracy/array/ in the patch title.
This is new one with applying your comment.
Thanks.
--8<--
>From 5d4f47d839ae4fc0796b633d41858d9c87fd235d Mon Sep 17 00:00:00 2001
From: Joonsoo Kim
Date: Fri, 30 Aug 2013 14:34:38 +0900
Subject: [PATCH v4 4/9] slab: factor out initialization of array cache
Factor out initialization of array cache to use it in following patch.
Acked-by: Christoph Lameter
Acked-by: David Rientjes
Signed-off-by: Joonsoo Kim
---
mm/slab.c | 33 +++--
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/mm/slab.c b/mm/slab.c
index 8f9e176..6fa3fdf 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -791,13 +791,8 @@ static void start_cpu_timer(int cpu)
}
}
-static struct array_cache *alloc_arraycache(int node, int entries,
- int batchcount, gfp_t gfp)
+static void init_arraycache(struct array_cache *ac, int limit, int batch)
{
- int memsize = sizeof(void *) * entries + sizeof(struct array_cache);
- struct array_cache *nc = NULL;
-
- nc = kmalloc_node(memsize, gfp, node);
/*
* The array_cache structures contain pointers to free object.
* However, when such objects are allocated or transferred to another
@@ -805,15 +800,25 @@ static struct array_cache *alloc_arraycache(int node, int
entries,
* valid references during a kmemleak scan. Therefore, kmemleak must
* not scan such objects.
*/
- kmemleak_no_scan(nc);
- if (nc) {
- nc->avail = 0;
- nc->limit = entries;
- nc->batchcount = batchcount;
- nc->touched = 0;
- spin_lock_init(>lock);
+ kmemleak_no_scan(ac);
+ if (ac) {
+ ac->avail = 0;
+ ac->limit = limit;
+ ac->batchcount = batch;
+ ac->touched = 0;
+ spin_lock_init(>lock);
}
- return nc;
+}
+
+static struct array_cache *alloc_arraycache(int node, int entries,
+ int batchcount, gfp_t gfp)
+{
+ int memsize = sizeof(void *) * entries + sizeof(struct array_cache);
+ struct array_cache *ac = NULL;
+
+ ac = kmalloc_node(memsize, gfp, node);
+ init_arraycache(ac, entries, batchcount);
+ return ac;
}
static inline bool is_slab_pfmemalloc(struct page *page)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/9] slab: defer slab_destroy in free_block()
On Tue, Jul 01, 2014 at 03:25:04PM -0700, David Rientjes wrote:
> On Tue, 1 Jul 2014, Joonsoo Kim wrote:
>
> > In free_block(), if freeing object makes new free slab and number of
> > free_objects exceeds free_limit, we start to destroy this new free slab
> > with holding the kmem_cache node lock. Holding the lock is useless and,
> > generally, holding a lock as least as possible is good thing. I never
> > measure performance effect of this, but we'd be better not to hold the lock
> > as much as possible.
> >
> > Commented by Christoph:
> > This is also good because kmem_cache_free is no longer called while
> > holding the node lock. So we avoid one case of recursion.
> >
> > Acked-by: Christoph Lameter
> > Signed-off-by: Joonsoo Kim
>
> Not sure what happened to my
>
> Acked-by: David Rientjes
>
> from http://marc.info/?l=linux-kernel=139951092124314, and for the
> record, I still think the free_block() "list" formal should be commented.
Really sorry about that.
My mail client didn't have this mail due to unknow reason, so I missed it.
Here goes the new one with applying your comment.
->8
>From 39d0bd43b978583a3e735a4bc9896447f7873153 Mon Sep 17 00:00:00 2001
From: Joonsoo Kim
Date: Thu, 29 Aug 2013 15:25:36 +0900
Subject: [PATCH v4 3/9] slab: defer slab_destroy in free_block()
In free_block(), if freeing object makes new free slab and number of
free_objects exceeds free_limit, we start to destroy this new free slab
with holding the kmem_cache node lock. Holding the lock is useless and,
generally, holding a lock as least as possible is good thing. I never
measure performance effect of this, but we'd be better not to hold the lock
as much as possible.
Commented by Christoph:
This is also good because kmem_cache_free is no longer called while
holding the node lock. So we avoid one case of recursion.
Acked-by: Christoph Lameter
Acked-by: David Rientjes
Signed-off-by: Joonsoo Kim
---
mm/slab.c | 64 ++---
1 file changed, 44 insertions(+), 20 deletions(-)
diff --git a/mm/slab.c b/mm/slab.c
index 19e2136..8f9e176 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -242,7 +242,8 @@ static struct kmem_cache_node __initdata
init_kmem_cache_node[NUM_INIT_LISTS];
static int drain_freelist(struct kmem_cache *cache,
struct kmem_cache_node *n, int tofree);
static void free_block(struct kmem_cache *cachep, void **objpp, int len,
- int node);
+ int node, struct list_head *list);
+static void slabs_destroy(struct kmem_cache *cachep, struct list_head *list);
static int enable_cpucache(struct kmem_cache *cachep, gfp_t gfp);
static void cache_reap(struct work_struct *unused);
@@ -1030,6 +1031,7 @@ static void __drain_alien_cache(struct kmem_cache *cachep,
struct array_cache *ac, int node)
{
struct kmem_cache_node *n = get_node(cachep, node);
+ LIST_HEAD(list);
if (ac->avail) {
spin_lock(>list_lock);
@@ -1041,9 +1043,10 @@ static void __drain_alien_cache(struct kmem_cache
*cachep,
if (n->shared)
transfer_objects(n->shared, ac, ac->limit);
- free_block(cachep, ac->entry, ac->avail, node);
+ free_block(cachep, ac->entry, ac->avail, node, );
ac->avail = 0;
spin_unlock(>list_lock);
+ slabs_destroy(cachep, );
}
}
@@ -1087,6 +1090,7 @@ static inline int cache_free_alien(struct kmem_cache
*cachep, void *objp)
struct kmem_cache_node *n;
struct array_cache *alien = NULL;
int node;
+ LIST_HEAD(list);
node = numa_mem_id();
@@ -,8 +1115,9 @@ static inline int cache_free_alien(struct kmem_cache
*cachep, void *objp)
} else {
n = get_node(cachep, nodeid);
spin_lock(>list_lock);
- free_block(cachep, , 1, nodeid);
+ free_block(cachep, , 1, nodeid, );
spin_unlock(>list_lock);
+ slabs_destroy(cachep, );
}
return 1;
}
@@ -1184,6 +1189,7 @@ static void cpuup_canceled(long cpu)
struct array_cache *nc;
struct array_cache *shared;
struct array_cache **alien;
+ LIST_HEAD(list);
/* cpu is dead; no one can alloc from it. */
nc = cachep->array[cpu];
@@ -1199,7 +1205,7 @@ static void cpuup_canceled(long cpu)
if (!memcg_cache_dead(cachep))
n->free_limit -= cachep->batchcount;
if (nc)
- free_block(cachep, nc->entry, nc->avail, node);
+ free_block(cachep, nc->entry, nc->avail, node, );
if (!cpumask_empty(mask)) {
spin_unlock_irq(>list_lock);
@@ -1209,7 +1215,7 @@ static void cpuup_canceled(long
Re: [PATCH 1/1] FS/BTRFS: replace count*size kzalloc by kcalloc
(2014/07/02 9:01), David Sterba wrote: On Wed, Jun 25, 2014 at 08:35:43PM +0200, Fabian Frederick wrote: kcalloc manages count*sizeof overflow. Cc: Chris Mason Cc: Josef Bacik Cc: linux-bt...@vger.kernel.org Signed-off-by: Fabian Frederick Reviewed-by: David Sterba Reviewed-by: Satoru Takeuchi -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] USB: ehci-pci: USB host controller support for Intel Quark X1000
On Tuesday, July 01, 2014 11:12 PM, Alan Stern wrote:
> On Tue, 1 Jul 2014, Chen, Alvin wrote:
>
> > From: Bryan O'Donoghue
> >
> > The EHCI packet buffer in/out threshold is programmable for Intel Quark
> > X1000
> > USB host controller, and the default value is 0x20 dwords. The in/out
> > threshold
> > can be programmed to 0x80 dwords (512 Bytes) to maximize the perfomrance,
> > but only when isochronous/interrupt transactions are not initiated by the
> > USB
> > host controller. This patch is to reconfigure the packet buffer in/out
> > threshold as maximal as possible to maximize the performance, and 0x7F
> > dwords
> > (508 Bytes) should be used because the USB host controller initiates
> > isochronous/interrupt transactions.
> >
> > Signed-off-by: Bryan O'Donoghue
> > Signed-off-by: Alvin (Weike) Chen
>
> Acked-by: Alan Stern
Reviewed-by: Jingoo Han
Best regards,
Jingoo Han
>
> There's one error in the style...
>
> > diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
> > index 3e86bf4..429434d 100644
> > --- a/drivers/usb/host/ehci-pci.c
> > +++ b/drivers/usb/host/ehci-pci.c
> > @@ -35,6 +35,21 @@ static const char hcd_name[] = "ehci-pci";
> > #define PCI_DEVICE_ID_INTEL_CE4100_USB 0x2e70
> >
> >
> > /*-*/
> > +#define PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC0x0939
> > +static inline bool is_intel_quark_x1000(struct pci_dev *pdev)
> > +{
> > + return pdev->vendor == PCI_VENDOR_ID_INTEL &&
> > + pdev->device == PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC;
> > +}
> > +
> > +/*
> > + * 0x84 is the offset of in/out threshold register,
> > + * and it is the same offset as the register of 'hostpc'.
> > + */
>
> This comment isn't formatted right. It should be like this:
>
> /*
> * blah blah blah
> * blah blah blah
> */
>
> If you want to submit a corrected version, you can. Or Greg may be
> willing to fix the style when he merges this patch.
>
> Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/9] slab: move up code to get kmem_cache_node in free_block()
On Tue, Jul 01, 2014 at 03:21:21PM -0700, David Rientjes wrote: > On Tue, 1 Jul 2014, Joonsoo Kim wrote: > > > node isn't changed, so we don't need to retreive this structure > > everytime we move the object. Maybe compiler do this optimization, > > but making it explicitly is better. > > > > Qualifying the pointer as const would be even more explicit. Hello, So what you recommend is something likes below? - struct kmem_cache_node *n = get_node(cachep, node); + struct kmem_cache_node * const n = get_node(cachep, node); I don't have seen this form of code protecting pointer itself in mm. Instead, I have seen 'const struct kmem_cache_node *n' which protects memory pointed by pointer. But this case isn't that case. Am I missing something? > > > Acked-by: Christoph Lameter > > Signed-off-by: Joonsoo Kim > > Acked-by: David Rientjes Thank you! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: mm: shmem: hang in shmem_fault (WAS: mm: shm: hang in shmem_fallocate)
On Tue, 1 Jul 2014, Sasha Levin wrote:
> Hi Hugh,
>
> I've been observing a very nonspecific hang involving some mutexes from fs/
> but
> without any lockdep output or a concrete way to track it down.
>
> It seems that today was my lucky day, and after enough tinkering I've managed
> to get output out of lockdep, which pointed me to shmem:
>
> [ 1871.989131] =
> [ 1871.990028] [ INFO: possible recursive locking detected ]
> [ 1871.992591] 3.16.0-rc3-next-20140630-sasha-00023-g44434d4-dirty #758
> Tainted: GW
> [ 1871.992591] -
> [ 1871.992591] trinity-c84/27757 is trying to acquire lock:
> [ 1871.992591] (>s_type->i_mutex_key#17){+.+.+.}, at: shmem_fault
> (mm/shmem.c:1289)
> [ 1871.992591]
> [ 1871.992591] but task is already holding lock:
> [ 1871.992591] (>s_type->i_mutex_key#17){+.+.+.}, at:
> generic_file_write_iter (mm/filemap.c:2633)
> [ 1871.992591]
> [ 1871.992591] other info that might help us debug this:
> [ 1871.992591] Possible unsafe locking scenario:
> [ 1871.992591]
> [ 1871.992591]CPU0
> [ 1871.992591]
> [ 1871.992591] lock(>s_type->i_mutex_key#17);
> [ 1871.992591] lock(>s_type->i_mutex_key#17);
> [ 1872.013889]
> [ 1872.013889] *** DEADLOCK ***
> [ 1872.013889]
> [ 1872.013889] May be due to missing lock nesting notation
> [ 1872.013889]
> [ 1872.013889] 3 locks held by trinity-c84/27757:
> [ 1872.013889] #0: (>f_pos_lock){+.+.+.}, at: __fdget_pos (fs/file.c:714)
> [ 1872.030221] #1: (sb_writers#13){.+.+.+}, at: do_readv_writev
> (include/linux/fs.h:2264 fs/read_write.c:830)
> [ 1872.030221] #2: (>s_type->i_mutex_key#17){+.+.+.}, at:
> generic_file_write_iter (mm/filemap.c:2633)
> [ 1872.030221]
> [ 1872.030221] stack backtrace:
> [ 1872.030221] CPU: 6 PID: 27757 Comm: trinity-c84 Tainted: GW
> 3.16.0-rc3-next-20140630-sasha-00023-g44434d4-dirty #758
> [ 1872.030221] 9fc112b0 8803c844f5d8 9c531022
> 0002
> [ 1872.030221] 9fc112b0 8803c844f6d8 991d1a8d
> 8803c5da3000
> [ 1872.030221] 8803c5da3d70 88030001 8803c5da3000
> 8803c5da3da8
> [ 1872.030221] Call Trace:
> [ 1872.030221] dump_stack (lib/dump_stack.c:52)
> [ 1872.030221] __lock_acquire (kernel/locking/lockdep.c:3034
> kernel/locking/lockdep.c:3180)
> [ 1872.030221] lock_acquire (./arch/x86/include/asm/current.h:14
> kernel/locking/lockdep.c:3602)
> [ 1872.030221] ? shmem_fault (mm/shmem.c:1289)
> [ 1872.030221] mutex_lock_nested (kernel/locking/mutex.c:486
> kernel/locking/mutex.c:587)
> [ 1872.030221] ? shmem_fault (mm/shmem.c:1289)
> [ 1872.030221] ? shmem_fault (mm/shmem.c:1288)
> [ 1872.030221] ? shmem_fault (mm/shmem.c:1289)
> [ 1872.030221] shmem_fault (mm/shmem.c:1289)
> [ 1872.030221] __do_fault (mm/memory.c:2705)
> [ 1872.030221] ? _raw_spin_unlock (./arch/x86/include/asm/preempt.h:98
> include/linux/spinlock_api_smp.h:152 kernel/locking/spinlock.c:183)
> [ 1872.030221] do_read_fault.isra.40 (mm/memory.c:2896)
> [ 1872.030221] ? get_parent_ip (kernel/sched/core.c:2550)
> [ 1872.030221] __handle_mm_fault (mm/memory.c:3037 mm/memory.c:3198
> mm/memory.c:3322)
> [ 1872.030221] handle_mm_fault (mm/memory.c:3345)
> [ 1872.030221] __do_page_fault (arch/x86/mm/fault.c:1230)
> [ 1872.030221] ? retint_restore_args (arch/x86/kernel/entry_64.S:829)
> [ 1872.030221] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
> [ 1872.030221] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2557
> kernel/locking/lockdep.c:2599)
> [ 1872.030221] ? context_tracking_user_exit (kernel/context_tracking.c:184)
> [ 1872.030221] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
> [ 1872.030221] ? trace_hardirqs_off_caller (kernel/locking/lockdep.c:2638
> (discriminator 2))
> [ 1872.030221] trace_do_page_fault (arch/x86/mm/fault.c:1313
> include/linux/jump_label.h:115 include/linux/context_tracking_state.h:27
> include/linux/context_tracking.h:45 arch/x86/mm/fault.c:1314)
> [ 1872.030221] do_async_page_fault (arch/x86/kernel/kvm.c:264)
> [ 1872.030221] async_page_fault (arch/x86/kernel/entry_64.S:1322)
> [ 1872.030221] ? iov_iter_fault_in_readable (include/linux/pagemap.h:598
> mm/iov_iter.c:267)
> [ 1872.030221] generic_perform_write (mm/filemap.c:2461)
> [ 1872.030221] ? __mnt_drop_write (./arch/x86/include/asm/preempt.h:98
> fs/namespace.c:455)
> [ 1872.030221] __generic_file_write_iter (mm/filemap.c:2608)
> [ 1872.030221] ? generic_file_llseek (fs/read_write.c:467)
> [ 1872.030221] generic_file_write_iter (mm/filemap.c:2634)
> [ 1872.030221] do_iter_readv_writev (fs/read_write.c:666)
> [ 1872.030221] do_readv_writev (fs/read_write.c:834)
> [ 1872.030221] ? __generic_file_write_iter (mm/filemap.c:2627)
> [ 1872.030221] ? __generic_file_write_iter (mm/filemap.c:2627)
> [ 1872.030221] ? mutex_lock_nested (./arch/x86/include/asm/preempt.h:98
> kernel/locking/mutex.c:570 kernel/locking/mutex.c:587)
> [
Re: [PATCH] serial: 8250_dw: support high baudrates if possible
On 07/01/2014 05:02 PM, One Thousand Gnomes wrote: > On Sat, 28 Jun 2014 15:15:56 -0500 > Alex Elder wrote: > >> On 06/28/2014 10:36 AM, One Thousand Gnomes wrote: >>> On Fri, 27 Jun 2014 12:25:20 -0500 + rate = 16 * max(115200U, (unsigned int)baud); + >>> >>> This assumes an arbitarily configurable clock, which is not I think the >>> usual case. >> >> If the clock's rate can't change, this will return an error, >> and the recorded rate (p->uartclk) will not be changed. > > Which assumes an arbitrarily configurable clock, whereas you want to find > the correct clock and multiplier combination for the baud rate. > > Most of these ports are wired to fixed clocks (which is fine) or clocks > with limited numbers of supported frequencies (which is not). Yes, I acknowledged that in my earlier response. But over the weekend I decided to abandon hope that I'd be able to verify there are no problems for affected machines, and re-formulated my patch. https://lkml.org/lkml/2014/7/1/323 > Your patch is an improvement but doesn't really fix the overall problem. > If we have enough devices with variable clocks for it to be useful then > fine - but can we merge it with a big FIXME note so that whoever comes > along wondering why their clock doesn't work or behaves very oddly can > figure it out and fix that case ? What I've done now is define a dw8250_adjustable_clk() predicate that indicates the UART baud can be adjusted by changing the clock rate. Anyone who wants to activate this functionality can just modify that function to recognize their device. -Alex > Alan > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/3] mm: Don't hide spin_lock in swap_info_get internal
Now, swap_info_get hides lock holding by doing it internally
but releasing the lock so caller should release the lock.
Normally, it's not a good pattern and I need to handle lock
from caller in next patchset.
Signed-off-by: Minchan Kim
---
mm/swapfile.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/mm/swapfile.c b/mm/swapfile.c
index 8798b2e0ac59..ec2ce926ea5f 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -740,7 +740,6 @@ static struct swap_info_struct *swap_info_get(swp_entry_t
entry)
goto bad_offset;
if (!p->swap_map[offset])
goto bad_free;
- spin_lock(>lock);
return p;
bad_free:
@@ -835,6 +834,7 @@ void swap_free(swp_entry_t entry)
p = swap_info_get(entry);
if (p) {
+ spin_lock(>lock);
swap_entry_free(p, entry, 1);
spin_unlock(>lock);
}
@@ -849,6 +849,7 @@ void swapcache_free(swp_entry_t entry)
p = swap_info_get(entry);
if (p) {
+ spin_lock(>lock);
swap_entry_free(p, entry, SWAP_HAS_CACHE);
spin_unlock(>lock);
}
@@ -868,6 +869,7 @@ int page_swapcount(struct page *page)
entry.val = page_private(page);
p = swap_info_get(entry);
if (p) {
+ spin_lock(>lock);
count = swap_count(p->swap_map[swp_offset(entry)]);
spin_unlock(>lock);
}
@@ -950,6 +952,7 @@ int free_swap_and_cache(swp_entry_t entry)
p = swap_info_get(entry);
if (p) {
+ spin_lock(>lock);
if (swap_entry_free(p, entry, 1) == SWAP_HAS_CACHE) {
page = find_get_page(swap_address_space(entry),
entry.val);
@@ -2763,6 +2766,7 @@ int add_swap_count_continuation(swp_entry_t entry, gfp_t
gfp_mask)
goto outer;
}
+ spin_lock(>lock);
offset = swp_offset(entry);
count = si->swap_map[offset] & ~SWAP_HAS_CACHE;
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/3] free reclaimed pages by paging out instantly
Normally, I/O completed pages for reclaim would be rotated into inactive LRU tail without freeing. The why it works is we can't free page from atomic context(ie, end_page_writeback) due to vaious locks isn't aware of atomic context. So for reclaiming the I/O completed pages, we need one more iteration of reclaim and it could make unnecessary aging as well as CPU overhead. Long time ago, at the first trial, most concern was memcg locking but recently, Johnannes tried amazing effort to make memcg lock simple and got merged into mmotm so I coded up based on mmotm tree. (Kudos to Johannes) On 1G, 12 CPU kvm guest, build kernel 5 times and result was allocstall vanilla: records: 5 avg: 4733.80 std: 913.55(19.30%) max: 6442.00 min: 3719.00 improve: records: 5 avg: 1514.20 std: 441.69(29.17%) max: 1974.00 min: 863.00 pgrotated vanilla: records: 5 avg: 873313.80 std: 40999.20(4.69%) max: 954722.00 min: 845903.00 improve: records: 5 avg: 28406.40 std: 3296.02(11.60%) max: 34552.00 min: 25047.00 Most of field in vmstat are not changed too much but things I can notice is allocstall and pgrotated. We could save allocstall(ie, direct relcaim) and pgrotated very much. Welcome testing, review and any feedback! * from v2 - 2014.06.20 * Rebased on v3.16-rc2-mmotm-2014-06-25-16-44 * Remove RFC tag Minchan Kim (3): mm: Don't hide spin_lock in swap_info_get internal mm: Introduce atomic_remove_mapping mm: Free reclaimed pages indepdent of next reclaim include/linux/swap.h | 4 mm/filemap.c | 17 +- mm/swap.c| 21 ++ mm/swapfile.c| 17 -- mm/vmscan.c | 63 5 files changed, 114 insertions(+), 8 deletions(-) -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/3] mm: Free reclaimed pages indepdent of next reclaim
Invalidate dirty/writeback page and file/swap I/O for reclaiming
are asynchronous so that when page writeback is completed,
it will be rotated back into LRU tail for freeing in next reclaim.
But it would make unnecessary CPU overhead and more aging
with higher priority of reclaim than necessary thing.
This patch makes such pages instant release when I/O complete
without LRU movement so that we could reduce reclaim events.
This patch wakes up one waiting PG_writeback and then clear
PG_reclaim bit because the page could be released during
rotating so it makes slighly race with Readahead logic but
the chance would be small and no huge side-effect even though
that happens, I belive.
Test result is as follows,
On 1G, 12 CPU kvm guest, build kernel 5 times and result was
allocstall
vanilla: records: 5 avg: 4733.80 std: 913.55(19.30%) max: 6442.00 min: 3719.00
improve: records: 5 avg: 1514.20 std: 441.69(29.17%) max: 1974.00 min: 863.00
pgrotated
vanilla: records: 5 avg: 873313.80 std: 40999.20(4.69%) max: 954722.00 min:
845903.00
improve: records: 5 avg: 28406.40 std: 3296.02(11.60%) max: 34552.00 min:
25047.00
Most of field in vmstat are not changed too much but things I can notice
is allocstall and pgrotated. We could save allocstall(ie, direct relcaim)
and pgrotated very much.
Signed-off-by: Minchan Kim
---
mm/filemap.c | 17 +++--
mm/swap.c| 21 +
2 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/mm/filemap.c b/mm/filemap.c
index c2f30ed8e95f..6e09de6cf510 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -752,23 +752,28 @@ EXPORT_SYMBOL(unlock_page);
*/
void end_page_writeback(struct page *page)
{
+ if (!test_clear_page_writeback(page))
+ BUG();
+
+ smp_mb__after_atomic();
+ wake_up_page(page, PG_writeback);
+
/*
* TestClearPageReclaim could be used here but it is an atomic
* operation and overkill in this particular case. Failing to
* shuffle a page marked for immediate reclaim is too mild to
* justify taking an atomic operation penalty at the end of
* ever page writeback.
+*
+* Clearing PG_reclaim after waking up waiter is slightly racy.
+* Readahead might see PageReclaim as PageReadahead marker
+* so readahead logic might be broken temporally but it isn't
+* matter enough to care.
*/
if (PageReclaim(page)) {
ClearPageReclaim(page);
rotate_reclaimable_page(page);
}
-
- if (!test_clear_page_writeback(page))
- BUG();
-
- smp_mb__after_atomic();
- wake_up_page(page, PG_writeback);
}
EXPORT_SYMBOL(end_page_writeback);
diff --git a/mm/swap.c b/mm/swap.c
index 3074210f245d..d61b8783ccc3 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -443,6 +443,27 @@ static void pagevec_move_tail_fn(struct page *page, struct
lruvec *lruvec,
if (PageLRU(page) && !PageActive(page) && !PageUnevictable(page)) {
enum lru_list lru = page_lru_base_type(page);
+ struct address_space *mapping;
+
+ if (!trylock_page(page))
+ goto move_tail;
+
+ mapping = page_mapping(page);
+ if (!mapping)
+ goto unlock;
+
+ /*
+* If it is successful, aotmic_remove_mapping
+* makes page->count one so the page will be
+* released when caller release his refcount.
+*/
+ if (atomic_remove_mapping(mapping, page)) {
+ unlock_page(page);
+ return;
+ }
+unlock:
+ unlock_page(page);
+move_tail:
list_move_tail(>lru, >lists[lru]);
(*pgmoved)++;
}
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/3] mm: Introduce atomic_remove_mapping
For release page from atomic context(ie, softirq), locks
related to the work should be aware of that.
There are two locks.
One is mapping->tree_lock and the other is swap_info_struct->lock.
The mapping->tree_lock is alreay aware of irq so it's no problem
but swap_info_struct->lock isn't so atomic_remove_mapping uses just
try_spinlock and if it fails to hold a lock, it just depends on
a fallback plan which moves the page into LRU's tail and expect page
freeing in next.
A change I know is mapping->a_ops->free is called on atomic context
by this patch. Only user is nfs_readdir_clear_array which is no
problem when I look at.
Cc: Trond Myklebust
Cc: linux-...@vger.kernel.org
Signed-off-by: Minchan Kim
---
include/linux/swap.h | 4
mm/swapfile.c| 11 -
mm/vmscan.c | 63
3 files changed, 77 insertions(+), 1 deletion(-)
diff --git a/include/linux/swap.h b/include/linux/swap.h
index 94fd0b23f3f9..5df540205bda 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -336,6 +336,8 @@ extern unsigned long mem_cgroup_shrink_node_zone(struct
mem_cgroup *mem,
unsigned long *nr_scanned);
extern unsigned long shrink_all_memory(unsigned long nr_pages);
extern int vm_swappiness;
+extern int atomic_remove_mapping(struct address_space *mapping,
+ struct page *page);
extern int remove_mapping(struct address_space *mapping, struct page *page);
extern unsigned long vm_total_pages;
@@ -441,6 +443,7 @@ static inline long get_nr_swap_pages(void)
}
extern void si_swapinfo(struct sysinfo *);
+extern struct swap_info_struct *swap_info_get(swp_entry_t entry);
extern swp_entry_t get_swap_page(void);
extern swp_entry_t get_swap_page_of_type(int);
extern int add_swap_count_continuation(swp_entry_t, gfp_t);
@@ -449,6 +452,7 @@ extern int swap_duplicate(swp_entry_t);
extern int swapcache_prepare(swp_entry_t);
extern void swap_free(swp_entry_t);
extern void swapcache_free(swp_entry_t);
+extern void __swapcache_free(swp_entry_t);
extern int free_swap_and_cache(swp_entry_t);
extern int swap_type_of(dev_t, sector_t, struct block_device **);
extern unsigned int count_swap_pages(int, int);
diff --git a/mm/swapfile.c b/mm/swapfile.c
index ec2ce926ea5f..d76496a8a104 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -722,7 +722,7 @@ swp_entry_t get_swap_page_of_type(int type)
return (swp_entry_t) {0};
}
-static struct swap_info_struct *swap_info_get(swp_entry_t entry)
+struct swap_info_struct *swap_info_get(swp_entry_t entry)
{
struct swap_info_struct *p;
unsigned long offset, type;
@@ -855,6 +855,15 @@ void swapcache_free(swp_entry_t entry)
}
}
+void __swapcache_free(swp_entry_t entry)
+{
+ struct swap_info_struct *p;
+
+ p = swap_info_get(entry);
+ if (p)
+ swap_entry_free(p, entry, SWAP_HAS_CACHE);
+}
+
/*
* How many references to page are currently swapped out?
* This does not give an exact answer when swap count is continued,
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 6d24fd63b209..31af369eef24 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -526,6 +526,69 @@ static pageout_t pageout(struct page *page, struct
address_space *mapping,
}
/*
+ * Attempt to detach a locked page from its ->mapping in atomic context.
+ * If it is dirty or if someone else has a ref on the page or couldn't
+ * get necessary locks, abort and return 0.
+ * If it was successfully detached, return 1.
+ * Assumes the caller has a single ref on this page.
+ */
+int atomic_remove_mapping(struct address_space *mapping,
+ struct page *page)
+{
+ BUG_ON(!PageLocked(page));
+ BUG_ON(mapping != page_mapping(page));
+ BUG_ON(!irqs_disabled());
+
+ spin_lock(>tree_lock);
+
+ /* Look at comment in __remove_mapping */
+ if (!page_freeze_refs(page, 2))
+ goto cannot_free;
+ /* note: atomic_cmpxchg in page_freeze_refs provides the smp_rmb */
+ if (unlikely(PageDirty(page))) {
+ page_unfreeze_refs(page, 2);
+ goto cannot_free;
+ }
+
+ if (PageSwapCache(page)) {
+ swp_entry_t swap = { .val = page_private(page) };
+ struct swap_info_struct *p = swap_info_get(swap);
+
+ if (!p || !spin_trylock(>lock)) {
+ page_unfreeze_refs(page, 2);
+ goto cannot_free;
+ }
+
+ mem_cgroup_swapout(page, swap);
+ __delete_from_swap_cache(page);
+ spin_unlock(>tree_lock);
+ __swapcache_free(swap);
+ spin_unlock(>lock);
+ } else {
+ void (*freepage)(struct page *);
+
+ freepage = mapping->a_ops->freepage;
+ __delete_from_page_cache(page, NULL);
+ spin_unlock(>tree_lock);
+
+
Re: [PATCH] hwpoison: Fix race with changing page during offlining v2
> > --- a/mm/memory-failure.c
> > +++ b/mm/memory-failure.c
> > @@ -1168,6 +1168,16 @@ int memory_failure(unsigned long pfn, int trapno,
> > int flags)
> > lock_page(hpage);
> >
> > /*
> > +* The page could have changed compound pages during the locking.
> > +* If this happens just bail out.
> > +*/
> > + if (compound_head(p) != hpage) {
>
> How can a 4k page change compound pages? The original compound page
> was torn down and then this 4k page became part of a differently-size
> compound page?
Yes or it was torn down and now it's its own page.
>
> > + action_result(pfn, "different compound page after locking",
> > IGNORED);
> > + res = -EBUSY;
> > + goto out;
> > + }
> > +
> > + /*
>
> I don't get it. We just go and fail the poisoning attempt? Shouldn't
> we go back, grab the new hpage and try again?
It should be quite rare, so I thought this was safest. An retry loop
would be more difficult to test and may have more side effects.
The hwpoison code by design only tries to handle cases that are
reasonably common in workloads, as visible in page-flags.
I'm not really that concerned about handling this (likely rare case),
just not crashing on it.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] FS/BTRFS: replace count*size kzalloc by kcalloc
On Wed, Jun 25, 2014 at 08:35:43PM +0200, Fabian Frederick wrote: > kcalloc manages count*sizeof overflow. > > Cc: Chris Mason > Cc: Josef Bacik > Cc: linux-bt...@vger.kernel.org > Signed-off-by: Fabian Frederick Reviewed-by: David Sterba -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.12 000/181] 3.12.24-stable review
On Mon, Jun 30, 2014 at 01:51:22PM +0200, Jiri Slaby wrote: > This is the start of the stable review cycle for the 3.12.24 release. > There are 181 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. . > Dave Chinner (3): > xfs: prevent deadlock trying to cover an active log > xfs: prevent stack overflows from page cache allocation > xfs: xfs_remove deadlocks due to inverted AGF vs AGI lock ordering None of the XFS patches you're backporting were marked for stable. What criteria did you choose them by, and how are you testing the result? Randomly picked XFS backports have a nasty habit of causing regressions, and it's always me that is on the pointy end of having to triage problems users report with those backports... Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: Add TMU dt node to monitor the temperature for Exynos3250
On 07/01/2014 01:10 PM, Sachin Kamat wrote:
> Hi Chanwoo,
>
> On Tue, Jul 1, 2014 at 9:34 AM, Chanwoo Choi wrote:
>> Hi Sachin,
>>
>> On 07/01/2014 12:33 PM, Sachin Kamat wrote:
>>> Hi Chanwoo,
>>>
>>> On Tue, Jul 1, 2014 at 6:10 AM, Chanwoo Choi wrote:
This patch add TMU (Thermal Management Unit) dt node to monitor the high
temperature for Exynos3250.
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
This patch has a dependency on following patch [1]:
[1] https://lkml.org/lkml/2014/6/30/805
arch/arm/boot/dts/exynos3250.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 3660cab..1e566af 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -192,6 +192,16 @@
status = "disabled";
};
+ tmu: tmu@100C {
+ compatible = "samsung,exynos3250-tmu";
+ interrupt-parent = <>;
+ reg = <0x100C 0x100>;
+ interrupts = <0 216 0>;
+ clocks = < CLK_TMU_APBIF>;
+ clock-names = "tmu_apbif";
+ status = "disabled";
>>>
>>> I don't think there would be any board specific properties needed. Hence
>>> leave the status as enabled (by deleting the above line).
>>>
>>
>> I think that if specific board need TMU feature, dts file for specific board
>> should include tmu dt node with 'okay' status. The specific board based on
>> Exynos3250 might not need TMU feature.
>
> The status field in DT node is not meant for stating the build configuration
> but
> represents the readiness of the hardware for usage on the platform. If
> a particular
> board does not need this feature it needs to be disabled in the build
> config and only
> for any special requirements disable it in board file.
TMU (Thermal Management Unit) needs specific regulator for TMU power as
following:
The regulator for TMU is dependent on board.
For exmaple: in board dts file including tmu dt
{
vtmu-supply = <_reg>;
status = "okay";
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 6/6] thermal: Add Tegra SOCTHERM thermal management driver
On 27/06/14 11:11, Mikko Perttunen wrote: + /* Sign extend from 6 bits to 32 bits */ + shifted_cp = (s32)((val & 0x1f) | ((val & 0x20) ? 0xffe0 : 0x0)); + val = ((val & (0x1f << 21)) >> 21); + /* Sign extend from 5 bits to 32 bits */ + shifted_ft = (s32)((val & 0xf) | ((val & 0x10) ? 0xfff0 : 0x0)); There's sign_extend32 in bitops.h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mm: make copy_pte_range static again
On Tue, 1 Jul 2014, Jerome Marchand wrote: > Commit 71e3aac (thp: transparent hugepage core) adds copy_pte_range > prototype to huge_mm.h. I'm not sure why (or if) this function have > been used outside of memory.c, but it currently isn't. > This patch makes copy_pte_range() static again. > > Signed-off-by: Jerome Marchand Acked-by: David Rientjes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/5] Improve sequential read throughput v4r8
On Wed, Jul 02, 2014 at 08:38:17AM +1000, Dave Chinner wrote: > On Tue, Jul 01, 2014 at 07:39:15PM +0100, Mel Gorman wrote: > > On Tue, Jul 01, 2014 at 01:16:11PM -0400, Johannes Weiner wrote: > > > On Mon, Jun 30, 2014 at 05:47:59PM +0100, Mel Gorman wrote: > > > Seqread throughput is up, randread takes a small hit. But allocation > > > latency is badly screwed at higher concurrency levels: > > > > So the results are roughly similar. You don't state which filesystem it is > > but FWIW if it's the ext3 filesystem using the ext4 driver then throughput > > at higher levels is also affected by filesystem fragmentation. The problem > > was outside the scope of the series. > > I'd suggest you're both going wrong that the "using ext3" point. > > Use ext4 or XFS for your performance measurements because that's > what everyone is using for the systems these days. iNot to mention > they don'thave all the crappy allocation artifacts that ext3 has, > nor the throughput limitations caused by the ext3 journal, and so > on. > > Fundamentally, ext3 performance is simply not a relevant performance > metric anymore - it's a legacy filesystem in maintenance mode and > has been for a few years now... > The problem crosses filesystems. ext3 is simply the first in the queue because by and large it behaved the worst. Covering the rest of them simply takes more time and with different results as you may expect. Here are the xfs results for the smaller of the machines as it was able to get that far before it got reset 3.16.0-rc2 3.0.0 3.16.0-rc2 vanilla vanilla fairzone-v4 MinSeqRead-MB/sec-1 92.69 ( 0.00%) 99.68 ( 7.54%) 104.47 ( 12.71%) MinSeqRead-MB/sec-2 106.81 ( 0.00%) 123.43 ( 15.56%) 123.24 ( 15.38%) MinSeqRead-MB/sec-4 101.89 ( 0.00%) 113.78 ( 11.67%) 116.85 ( 14.68%) MinSeqRead-MB/sec-8 95.31 ( 0.00%) 91.40 ( -4.10%) 101.68 ( 6.68%) MinSeqRead-MB/sec-16 81.84 ( 0.00%) 88.53 ( 8.17%) 86.63 ( 5.85%) -- Mel Gorman SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Add "rpm_not_supported" flag
On Monday, June 30, 2014 10:42:19 AM Alan Stern wrote: > On Mon, 30 Jun 2014, Rafael J. Wysocki wrote: > > > > > Do you know of any tools that actually look at these files? > > > > > > I don't. Of course, that doesn't mean much. > > > > The only tool I'm aware of that may be looking at them is powertop, so > > if the change doesn't affect powertop adversely, it should be generally > > safe. > > > > > > If there isn't any, then we can try to change it and see who screams :) > > > > > > It'll be a learning experience... > > > > Yes, it will. :-) > > Then you have no other objections to the patch? My concern still is that it will be confusing, because people won't read the documentation carefully enough and will confuse "runtime PM never used" with "hardware can't do PM". I'm not sure how to make that more clear, though. Also we have the no_callbacks flag and I wonder if/how it is related to the new one. Do we still need both? In addition to that, I think that "hardware can't do PM" should apply to the handling of system suspend resume too. Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
FIX ME in function ocpi_enable in file arch/arm/mach-omap1/opci.c
Hey Tony and Russel , There is a FIX ME message in this function of the file stated in my subject line. I was wondering what locking is needed here due to not having experience with omap subsystem(s). Cheers Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 driver-core-linus] kernfs: kernfs_notify() must be useable from non-sleepable contexts
On Tue, Jul 01, 2014 at 04:41:03PM -0400, Tejun Heo wrote:
> d911d9874801 ("kernfs: make kernfs_notify() trigger inotify events
> too") added fsnotify triggering to kernfs_notify() which requires a
> sleepable context. There are already existing users of
> kernfs_notify() which invoke it from an atomic context and in general
> it's silly to require a sleepable context for triggering a
> notification.
>
> The following is an invalid context bug triggerd by md invoking
> sysfs_notify() from IO completion path.
>
> BUG: sleeping function called from invalid context at
> kernel/locking/mutex.c:586
> in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/1
> 2 locks held by swapper/1/0:
> #0: (&(>vq_lock)->rlock){-.-...}, at: []
> virtblk_done+0x42/0xe0 [virtio_blk]
> #1: (&(>counts.lock)->rlock){-.}, at: []
> bitmap_endwrite+0x68/0x240
> irq event stamp: 33518
> hardirqs last enabled at (33515): []
> default_idle+0x1f/0x230
> hardirqs last disabled at (33516): []
> common_interrupt+0x6d/0x72
> softirqs last enabled at (33518): []
> _local_bh_enable+0x22/0x50
> softirqs last disabled at (33517): [] irq_enter+0x60/0x80
> CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.16.0-0.rc2.git2.1.fc21.x86_64 #1
> Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> f90db13964f4ee05 88007d403b80 81807b4c
> 88007d403ba8 810d4f14
> 00441800 880078fa1780 88007d403c38 8180caf2
> Call Trace:
> [] dump_stack+0x4d/0x66
> [] __might_sleep+0x184/0x240
> [] mutex_lock_nested+0x42/0x440
> [] kernfs_notify+0x90/0x150
> [] bitmap_endwrite+0xcc/0x240
> [] close_write+0x93/0xb0 [raid1]
> [] r1_bio_write_done+0x29/0x50 [raid1]
> [] raid1_end_write_request+0xe4/0x260 [raid1]
> [] bio_endio+0x6b/0xa0
> [] blk_update_request+0x94/0x420
> [] blk_mq_end_io+0x1a/0x70
> [] virtblk_request_done+0x32/0x80 [virtio_blk]
> [] __blk_mq_complete_request+0x88/0x120
> [] blk_mq_complete_request+0x2a/0x30
> [] virtblk_done+0x66/0xe0 [virtio_blk]
> [] vring_interrupt+0x3a/0xa0 [virtio_ring]
> [] handle_irq_event_percpu+0x77/0x340
> [] handle_irq_event+0x3d/0x60
> [] handle_edge_irq+0x66/0x130
> [] handle_irq+0x84/0x150
> [] do_IRQ+0x4d/0xe0
> [] common_interrupt+0x72/0x72
> [] ? native_safe_halt+0x6/0x10
> [] default_idle+0x24/0x230
> [] arch_cpu_idle+0xf/0x20
> [] cpu_startup_entry+0x37c/0x7b0
> [] start_secondary+0x25b/0x300
>
> This patch fixes it by punting the notification delivery through a
> work item. This ends up adding an extra pointer to kernfs_elem_attr
> enlarging kernfs_node by a pointer, which is not ideal but not a very
> big deal either. If this turns out to be an actual issue, we can move
> kernfs_elem_attr->size to kernfs_node->iattr later.
>
> Signed-off-by: Tejun Heo
> Reported-by: Josh Boyer
> Cc: "Michael S. Tsirkin"
> Cc: Jens Axboe
> ---
> fs/kernfs/file.c | 69
> +++--
> include/linux/kernfs.h |1
> 2 files changed, 56 insertions(+), 14 deletions(-)
Looks good to me, do you want to take this with your other kernfs
patches for 3.16-final? Or if you don't have that, I can take it
through my tree, it's your choice, either is fine for me.
If you want it in your tree, feel free to add:
Acked-by: Greg Kroah-Hartman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 49/50] mars: generic pre-patch for mars
On Tue, Jul 01, 2014 at 11:47:29PM +0200, Thomas Schoebel-Theuer wrote: > From: Thomas Schoebel-Theuer > > Mostly introduces missing EXPORT_SYMBOL(). > Should have no impact onto the kernel. > > This is the generic version which exports all sys_*() system > calls. This should not introduce any additional maintenance pain > because that interfaces has to be stable anyway due to POSIX etc. > > Signed-off-by: Thomas Schoebel-Theuer > --- > fs/open.c | 1 - > fs/utimes.c| 2 ++ > include/linux/syscalls.h | 3 +++ > include/uapi/linux/major.h | 1 + > mm/page_alloc.c| 3 +++ > 5 files changed, 9 insertions(+), 1 deletion(-) > > diff --git a/fs/open.c b/fs/open.c > index 36662d0..3b21b76 100644 > --- a/fs/open.c > +++ b/fs/open.c > @@ -1064,7 +1064,6 @@ SYSCALL_DEFINE1(close, unsigned int, fd) > > return retval; > } > -EXPORT_SYMBOL(sys_close); > > /* > * This routine simulates a hangup on the tty, to arrange that users > diff --git a/fs/utimes.c b/fs/utimes.c > index aa138d6..4a1f4a8 100644 > --- a/fs/utimes.c > +++ b/fs/utimes.c > @@ -1,3 +1,4 @@ > +#include > #include > #include > #include > @@ -181,6 +182,7 @@ retry: > out: > return error; > } > +EXPORT_SYMBOL(do_utimes); > > SYSCALL_DEFINE4(utimensat, int, dfd, const char __user *, filename, > struct timespec __user *, utimes, int, flags) > diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h > index b0881a0..c674309 100644 > --- a/include/linux/syscalls.h > +++ b/include/linux/syscalls.h > @@ -75,6 +75,7 @@ struct sigaltstack; > #include > #include > #include > +#include > #include > #include > #include > @@ -176,6 +177,7 @@ extern struct trace_event_functions > exit_syscall_print_funcs; > > #define SYSCALL_DEFINE0(sname) \ > SYSCALL_METADATA(_##sname, 0); \ > + EXPORT_SYMBOL(sys_##sname); \ > asmlinkage long sys_##sname(void) > > #define SYSCALL_DEFINE1(name, ...) SYSCALL_DEFINEx(1, _##name, __VA_ARGS__) > @@ -202,6 +204,7 @@ extern struct trace_event_functions > exit_syscall_print_funcs; > __PROTECT(x, ret,__MAP(x,__SC_ARGS,__VA_ARGS__)); \ > return ret; \ > } \ > + EXPORT_SYMBOL(sys##name); \ > static inline long SYSC##name(__MAP(x,__SC_DECL,__VA_ARGS__)) > Heh, nice try, but no, we aren't going to export all syscalls, that's crazy. And wrong on many levels, sorry. Be explicit with your exports, and justify _why_ you need them. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [GIT PULL] KVM changes for 3.16-rc4
Il 01/07/2014 19:47, Linus Torvalds ha scritto: Merges need explanations too. Tell what the branch you are merging does, and why you are doing the merge. Yeah, in this case the "branch" contains a single commit, but that *still* doesn't excuse not telling what the merge is, and why it exists at all. Seriously. Do "git log --merges" on current git, and look at the discrepancy between merge commit messages. That commit 9a630d15f16d is pure garbage. It's not the only crappy one, but it really does stand out. There are other one-liners in there, but even then they tend to have at least *some* semblance of actual information in them, ie Merge branch 'for-v3.16/ti-clk-drv' of github.com:t-kristo/linux-pm into clk-next at least shows that there's a topic branch with a reasonable name, and where it comes from. I'd really prefer it to talk about what it merges and why, but it's still *much* better than your completely information-free merge message. You're definitely right about the poor commit message. I made this a merge because I really wanted this commit in the 3.17 development branch too. So I applied the patch on top of -rc1 and merged it into both branches (kvm-master for 3.16 and kvm-next for 3.17). For some reason, I did see a need to justify the merge commit in kvm-next: commit dc720f95939280f9e69cafe7389be6d0fa6f22dd Merge: 27e6fb5dae28 33b458d276bb Author: Paolo Bonzini Date: Mon Jun 30 16:51:07 2014 +0200 Merge commit '33b458d276bb' into kvm-next Fix bad x86 regression introduced during merge window. Probably still not verbose enough, but a little better. Am I just over-engineering it and I should have simply cherry-picked it? In this particular case the change is not likely to get other changes (and thus conflicts) in kvm-next, but in general it could. Thanks, Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 0/2] ARM: at91: remove phy fixup for sama5d3xek boards
From: Boris BREZILLON Date: Thu, 26 Jun 2014 12:13:33 +0200 > This patch removes a board specific hook for sama5d3xek boards from the > sama5d3 generic DT board file. > > This hook (which register a phy fixup configuring board specific delays > in the ksz9021 ethernet phy) is now replaced by the appropriate DT > properties definitions in the sama5d3xcm.dtsi file. > > Changes since v1: > - fix txc-skew-ps and rxc-skew-ps delays > - remove phy address info to handle Ronetix and Embest HW designs These patches do not apply cleanly to 'net' nor 'net-next', in fact you did not even say which tree these changes are targetting. Please respin these patches and explicitly say what tree you wish them to be applied to. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Improve sequential read throughput v4r8
On Tue, Jul 01, 2014 at 07:39:15PM +0100, Mel Gorman wrote: > On Tue, Jul 01, 2014 at 01:16:11PM -0400, Johannes Weiner wrote: > > On Mon, Jun 30, 2014 at 05:47:59PM +0100, Mel Gorman wrote: > > Seqread throughput is up, randread takes a small hit. But allocation > > latency is badly screwed at higher concurrency levels: > > So the results are roughly similar. You don't state which filesystem it is > but FWIW if it's the ext3 filesystem using the ext4 driver then throughput > at higher levels is also affected by filesystem fragmentation. The problem > was outside the scope of the series. I'd suggest you're both going wrong that the "using ext3" point. Use ext4 or XFS for your performance measurements because that's what everyone is using for the systems these days. iNot to mention they don'thave all the crappy allocation artifacts that ext3 has, nor the throughput limitations caused by the ext3 journal, and so on. Fundamentally, ext3 performance is simply not a relevant performance metric anymore - it's a legacy filesystem in maintenance mode and has been for a few years now... Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
mm: shmem: hang in shmem_fault (WAS: mm: shm: hang in shmem_fallocate)
Hi Hugh,
I've been observing a very nonspecific hang involving some mutexes from fs/ but
without any lockdep output or a concrete way to track it down.
It seems that today was my lucky day, and after enough tinkering I've managed
to get output out of lockdep, which pointed me to shmem:
[ 1871.989131] =
[ 1871.990028] [ INFO: possible recursive locking detected ]
[ 1871.992591] 3.16.0-rc3-next-20140630-sasha-00023-g44434d4-dirty #758
Tainted: GW
[ 1871.992591] -
[ 1871.992591] trinity-c84/27757 is trying to acquire lock:
[ 1871.992591] (>s_type->i_mutex_key#17){+.+.+.}, at: shmem_fault
(mm/shmem.c:1289)
[ 1871.992591]
[ 1871.992591] but task is already holding lock:
[ 1871.992591] (>s_type->i_mutex_key#17){+.+.+.}, at:
generic_file_write_iter (mm/filemap.c:2633)
[ 1871.992591]
[ 1871.992591] other info that might help us debug this:
[ 1871.992591] Possible unsafe locking scenario:
[ 1871.992591]
[ 1871.992591]CPU0
[ 1871.992591]
[ 1871.992591] lock(>s_type->i_mutex_key#17);
[ 1871.992591] lock(>s_type->i_mutex_key#17);
[ 1872.013889]
[ 1872.013889] *** DEADLOCK ***
[ 1872.013889]
[ 1872.013889] May be due to missing lock nesting notation
[ 1872.013889]
[ 1872.013889] 3 locks held by trinity-c84/27757:
[ 1872.013889] #0: (>f_pos_lock){+.+.+.}, at: __fdget_pos (fs/file.c:714)
[ 1872.030221] #1: (sb_writers#13){.+.+.+}, at: do_readv_writev
(include/linux/fs.h:2264 fs/read_write.c:830)
[ 1872.030221] #2: (>s_type->i_mutex_key#17){+.+.+.}, at:
generic_file_write_iter (mm/filemap.c:2633)
[ 1872.030221]
[ 1872.030221] stack backtrace:
[ 1872.030221] CPU: 6 PID: 27757 Comm: trinity-c84 Tainted: GW
3.16.0-rc3-next-20140630-sasha-00023-g44434d4-dirty #758
[ 1872.030221] 9fc112b0 8803c844f5d8 9c531022
0002
[ 1872.030221] 9fc112b0 8803c844f6d8 991d1a8d
8803c5da3000
[ 1872.030221] 8803c5da3d70 88030001 8803c5da3000
8803c5da3da8
[ 1872.030221] Call Trace:
[ 1872.030221] dump_stack (lib/dump_stack.c:52)
[ 1872.030221] __lock_acquire (kernel/locking/lockdep.c:3034
kernel/locking/lockdep.c:3180)
[ 1872.030221] lock_acquire (./arch/x86/include/asm/current.h:14
kernel/locking/lockdep.c:3602)
[ 1872.030221] ? shmem_fault (mm/shmem.c:1289)
[ 1872.030221] mutex_lock_nested (kernel/locking/mutex.c:486
kernel/locking/mutex.c:587)
[ 1872.030221] ? shmem_fault (mm/shmem.c:1289)
[ 1872.030221] ? shmem_fault (mm/shmem.c:1288)
[ 1872.030221] ? shmem_fault (mm/shmem.c:1289)
[ 1872.030221] shmem_fault (mm/shmem.c:1289)
[ 1872.030221] __do_fault (mm/memory.c:2705)
[ 1872.030221] ? _raw_spin_unlock (./arch/x86/include/asm/preempt.h:98
include/linux/spinlock_api_smp.h:152 kernel/locking/spinlock.c:183)
[ 1872.030221] do_read_fault.isra.40 (mm/memory.c:2896)
[ 1872.030221] ? get_parent_ip (kernel/sched/core.c:2550)
[ 1872.030221] __handle_mm_fault (mm/memory.c:3037 mm/memory.c:3198
mm/memory.c:3322)
[ 1872.030221] handle_mm_fault (mm/memory.c:3345)
[ 1872.030221] __do_page_fault (arch/x86/mm/fault.c:1230)
[ 1872.030221] ? retint_restore_args (arch/x86/kernel/entry_64.S:829)
[ 1872.030221] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
[ 1872.030221] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2557
kernel/locking/lockdep.c:2599)
[ 1872.030221] ? context_tracking_user_exit (kernel/context_tracking.c:184)
[ 1872.030221] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
[ 1872.030221] ? trace_hardirqs_off_caller (kernel/locking/lockdep.c:2638
(discriminator 2))
[ 1872.030221] trace_do_page_fault (arch/x86/mm/fault.c:1313
include/linux/jump_label.h:115 include/linux/context_tracking_state.h:27
include/linux/context_tracking.h:45 arch/x86/mm/fault.c:1314)
[ 1872.030221] do_async_page_fault (arch/x86/kernel/kvm.c:264)
[ 1872.030221] async_page_fault (arch/x86/kernel/entry_64.S:1322)
[ 1872.030221] ? iov_iter_fault_in_readable (include/linux/pagemap.h:598
mm/iov_iter.c:267)
[ 1872.030221] generic_perform_write (mm/filemap.c:2461)
[ 1872.030221] ? __mnt_drop_write (./arch/x86/include/asm/preempt.h:98
fs/namespace.c:455)
[ 1872.030221] __generic_file_write_iter (mm/filemap.c:2608)
[ 1872.030221] ? generic_file_llseek (fs/read_write.c:467)
[ 1872.030221] generic_file_write_iter (mm/filemap.c:2634)
[ 1872.030221] do_iter_readv_writev (fs/read_write.c:666)
[ 1872.030221] do_readv_writev (fs/read_write.c:834)
[ 1872.030221] ? __generic_file_write_iter (mm/filemap.c:2627)
[ 1872.030221] ? __generic_file_write_iter (mm/filemap.c:2627)
[ 1872.030221] ? mutex_lock_nested (./arch/x86/include/asm/preempt.h:98
kernel/locking/mutex.c:570 kernel/locking/mutex.c:587)
[ 1872.030221] ? __fdget_pos (fs/file.c:714)
[ 1872.030221] ? __fdget_pos (fs/file.c:714)
[ 1872.030221] ? __fget_light (include/linux/rcupdate.h:402
include/linux/fdtable.h:80 fs/file.c:684)
[ 1872.101905] vfs_writev (fs/read_write.c:879)
[
