Re: [PATCH 06/14] net: dsa: Add support for hardware monitoring
Le 23/10/2014 22:40, Guenter Roeck a écrit : On 10/23/2014 10:03 PM, David Miller wrote: From: Guenter Roeck Date: Wed, 22 Oct 2014 22:06:41 -0700 On 10/22/2014 09:37 PM, Florian Fainelli wrote: 2014-10-22 21:03 GMT-07:00 Guenter Roeck : Some Marvell switches provide chip temperature data. Add support for reporting it to the dsa infrastructure. Signed-off-by: Guenter Roeck --- [snip] +/* hwmon support / + +#if defined(CONFIG_HWMON) || (defined(MODULE) && defined(CONFIG_HWMON_MODULE)) IS_ENABLED(CONFIG_HWMON)? Hi Florian, unfortunately, that won't work; I had it initially and got a nice error message from Fengguang's build test bot. Then the Kconfig dependencies are broken. Fix Kconfig to only allow legal combinations. I see two options for that: - Add select HWMON to the NET_DSA Kconfig entry. Example is Broadcom TIGON3 driver. - Add a DSA_HWMON Kconfig entry to define the dependencies and to let the user select if the functionality should be enabled. Example is Intel IGB driver. Any preference from your side ? If no, I'll go with the latter. I would prefer DSA_HWMON personaly, though no strong feelings. Since this is the most debated patch in this patch set, how about you drop it from your v2 and we sort this one out separately? -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] net: dsa: Add support for hardware monitoring
On 10/23/2014 10:03 PM, David Miller wrote: From: Guenter Roeck Date: Wed, 22 Oct 2014 22:06:41 -0700 On 10/22/2014 09:37 PM, Florian Fainelli wrote: 2014-10-22 21:03 GMT-07:00 Guenter Roeck : Some Marvell switches provide chip temperature data. Add support for reporting it to the dsa infrastructure. Signed-off-by: Guenter Roeck --- [snip] +/* hwmon support / + +#if defined(CONFIG_HWMON) || (defined(MODULE) && defined(CONFIG_HWMON_MODULE)) IS_ENABLED(CONFIG_HWMON)? Hi Florian, unfortunately, that won't work; I had it initially and got a nice error message from Fengguang's build test bot. Then the Kconfig dependencies are broken. Fix Kconfig to only allow legal combinations. I see two options for that: - Add select HWMON to the NET_DSA Kconfig entry. Example is Broadcom TIGON3 driver. - Add a DSA_HWMON Kconfig entry to define the dependencies and to let the user select if the functionality should be enabled. Example is Intel IGB driver. Any preference from your side ? If no, I'll go with the latter. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/16] perf tools: Add a thread stack for synthesizing call chains
On Thu, 23 Oct 2014 13:45:12 +0300, Adrian Hunter wrote:
> +static void thread_stack__pop(struct thread_stack *ts, u64 ret_addr)
> +{
> + if (!ts->cnt)
> + return;
> +
> + if (ts->stack[ts->cnt - 1].ret_addr == ret_addr) {
> + ts->cnt -= 1;
> + } else {
> + size_t i = ts->cnt - 1;
> +
> + while (i--) {
> + if (ts->stack[i].ret_addr == ret_addr) {
> + ts->cnt = i;
> + return;
> + }
> + }
> + }
> +}
Why not making it a single loop like:
int i;
for (i = ts->cnt - 1; i >= 0; i--) {
if (ts->stack[i].ret_addr == ret_addr) {
ts->cnt = i;
return;
}
}
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/
[PATCH v4 8/8] ARM: mediatek: Fix description for mediatek SoCs
From: "Joe.C" We support more MediaTek SoCs now, update the description. Signed-off-by: Joe.C --- arch/arm/mach-mediatek/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-mediatek/Kconfig b/arch/arm/mach-mediatek/Kconfig index 2c043a2..f73f588 100644 --- a/arch/arm/mach-mediatek/Kconfig +++ b/arch/arm/mach-mediatek/Kconfig @@ -1,6 +1,6 @@ config ARCH_MEDIATEK - bool "Mediatek MT6589 SoC" if ARCH_MULTI_V7 + bool "Mediatek MT65xx & MT81xx SoC" if ARCH_MULTI_V7 select ARM_GIC select MTK_TIMER help - Support for Mediatek Cortex-A7 Quad-Core-SoC MT6589. + Support for Mediatek MT65xx & MT81xx SoCs -- 1.8.1.1.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH resending] splice: sendfile() at once fails for big files
When big files (over 64kbytes) are sent with sendfile(), they are sent by blocks
of 64kbytes. In that case, the target must be informed that the current block is
not the last one, otherwise it might take wrong actions.
The issue was observed while sending a file to an AF_ALG socket for hashing. The
hash was reset at each 64k block.
This patch adds SPLICE_F_MORE to the flags when more data is pending.
Signed-off-by: Christophe Leroy
Index: b/fs/splice.c
===
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -1171,7 +1171,7 @@
long ret, bytes;
umode_t i_mode;
size_t len;
- int i, flags;
+ int i, flags, more;
/*
* We require the input being a regular file, as we don't want to
@@ -1214,6 +1214,7 @@
* Don't block on output, we have to drain the direct pipe.
*/
sd->flags &= ~SPLICE_F_NONBLOCK;
+ more = sd->flags & SPLICE_F_MORE;
while (len) {
size_t read_len;
@@ -1226,6 +1227,10 @@
read_len = ret;
sd->total_len = read_len;
+ if (read_len < len)
+ sd->flags |= SPLICE_F_MORE;
+ else if (!more)
+ sd->flags &= ~SPLICE_F_MORE;
/*
* NOTE: nonblocking mode only applies to the input. We
* must not do the output in nonblocking mode as then we
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/4] fix freepage count problems in memory isolation
On Fri, Oct 24, 2014 at 11:27:49AM +0900, Minchan Kim wrote: > Hi Joonsoo, > > I know you spend much effort for investigate/fix this subtle problem. > So, you should be hero. > > Thanks for really nice work! Hello, Thanks. :) > > > > Joonsoo Kim (4): > > mm/page_alloc: fix incorrect isolation behavior by rechecking > > migratetype > > mm/page_alloc: add freepage on isolate pageblock to correct buddy > > list > > mm/page_alloc: move migratetype recheck logic to __free_one_page() > > So, [1-3], > Acked-by: Minchan Kim Thanks, too. > > mm/page_alloc: restrict max order of merging on isolated pageblock > > As you noted in description, this patch has a side effect which doesn't > merge buddies. Most of all, I agree your assumptions but it's not true always. > > Who knows there is a driver which want a higher page above pageblock? > Who knows there is no allocation/free of the isolated range right before > highest allocation request? > Even, your patch introduces new exception rule for page allocator. > > "Hey, allocator, from now on, you could have unmerged buddies > in your list so please advertise it to your customer" > > So, all of users of the allocator should consider that exception so > it might hit us sometime. > > I want to fix that in isolation undo time. > Thanks, again! Okay. I will try it. The reason I implement as current is that it makes process of isolation/un-isolation asymetric and needs to copy and paste some code to handle this specialty. That would possibly result in maintainance overhead. But, yes, exception of buddy property is also bad situation. I will implement it and send it soon. 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 net] bpf: split eBPF out of NET
On Thu, Oct 23, 2014 at 8:23 PM, Josh Triplett wrote:
> On Thu, Oct 23, 2014 at 06:41:08PM -0700, Alexei Starovoitov wrote:
>> introduce two configs:
>> - hidden CONFIG_BPF to select eBPF interpreter that classic socket filters
>> depend on
>> - visible CONFIG_BPF_SYSCALL (default off) that tracing and sockets can use
>>
>> that solves several problems:
>> - tracing and others that wish to use eBPF don't need to depend on NET.
>> They can use BPF_SYSCALL to allow loading from userspace or select BPF
>> to use it directly from kernel in NET-less configs.
>> - in 3.18 programs cannot be attached to events yet, so don't force it on
>> - when the rest of eBPF infra is there in 3.19+, it's still useful to
>> switch it off to minimize kernel size
>>
>> Signed-off-by: Alexei Starovoitov
>
> Thanks for working on this! A few nits below, but otherwise this looks
> good to me. Once this gets appropriate reviews from net and bpf folks,
> please let me know if you want this to go through the net tree, the tiny
> tree, or some other tree.
Thanks :)
I've sent it to Dave and marked it as 'net', so it's for
his net tree. I don't mind if he decides to steer it into net-next
when it opens, since changing Kconfig is always tricky.
I just felt that this patch deserves to be in 'net' and in 3.18-rc
>> bloat-o-meter on x64 shows:
>> add/remove: 0/60 grow/shrink: 0/2 up/down: 0/-15601 (-15601)
>
> Very nice! Please do include the bloat-o-meter stats in the commit
> message.
I don't think that's necessary. eBPF is in early stages of adoption.
More things to come, so bloat-o-meter stats will be obsolete
very quickly.
>> +# interpreter that classic socket filters depend on
>> +config BPF
>> + boolean
>
> s/boolean/bool/
Is there a difference? I thought it's an alias.
>> +config BPF_SYSCALL
>> + bool "Enable bpf() system call" if EXPERT
>> + select ANON_INODES
>> + select BPF
>> + default n
>> + help
>> + Enable the bpf() system call that allows to manipulate eBPF
>> + programs and maps via file descriptors.
>
> Not sure this one goes under EXPERT, especially since it currently has
> "default n".
I followed the same style as EPOLL, EVENTFD and others
in the same category.
>> +/* To execute LD_ABS/LD_IND instructions __bpf_prog_run() may call
>> + * skb_copy_bits(), so provide a weak definition of it for NET-less config.
>> + */
>> +int __weak skb_copy_bits(const struct sk_buff *skb, int offset, void *to,
>> + int len)
>> +{
>> + return -EFAULT;
>> +}
>
> Please discuss this in the commit message. What are the implications of
> ending up with this implementation that always returns -EFAULT?
because that's what real skb_copy_bits() would return.
In this case it's actually irrelevant, since non-socket programs
are not allowed to have LD_ABS/LD_IND instructions and
I'm only resolving linker error here.
But returning negative error helps prevent bugs in cases
where verifier or some in-kernel generated program uses
LD_ABS by mistake.
I don't think these type of explanations are necessary in
commit logs.
>> @@ -6,7 +6,7 @@ menuconfig NET
>> bool "Networking support"
>> select NLATTR
>> select GENERIC_NET_UTILS
>> - select ANON_INODES
>> + select BPF
>
> Why does this not need to select ANON_INODES anymore? Did *only* BPF
> use that, so it only needs to occur via BPF_SYSCALL? If so, can you
> document that in the commit message?
I hope that folks who were following this work on netdev
remember commit 38b3629adb8c04 that added it.
So here I'm actually removing this ANON_INODES dependency
from NET and moving it into BPF_SYSCALL where it belongs.
btw, the goal of this patch is not tinification, but rather being
good citizen and not forcing new syscall on everyone.
It was tested with upcoming tracing patches that select
BPF instead of NET.
It will also help parallelize the development, since my old
predicate-tree into eBPF optimization for vanilla tracing filters:
http://lwn.net/Articles/598545/
can potentially go into tip tree a release earlier.
Back then full NET dependency was a show stopper.
This patch finally addresses it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] (CMA_AGGRESSIVE) Update page alloc function
On Thu, Oct 16, 2014 at 11:35:51AM +0800, Hui Zhu wrote:
> If page alloc function __rmqueue try to get pages from MIGRATE_MOVABLE and
> conditions (cma_alloc_counter, cma_aggressive_free_min, cma_alloc_counter)
> allow, MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first.
>
> Signed-off-by: Hui Zhu
> ---
> mm/page_alloc.c | 42 +++---
> 1 file changed, 31 insertions(+), 11 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 736d8e1..87bc326 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -65,6 +65,10 @@
> #include
> #include "internal.h"
>
> +#ifdef CONFIG_CMA_AGGRESSIVE
> +#include
> +#endif
> +
> /* prevent >1 _updater_ of zone percpu pageset ->high and ->batch fields */
> static DEFINE_MUTEX(pcp_batch_high_lock);
> #define MIN_PERCPU_PAGELIST_FRACTION (8)
> @@ -1189,20 +1193,36 @@ static struct page *__rmqueue(struct zone *zone,
> unsigned int order,
> {
> struct page *page;
>
> -retry_reserve:
> +#ifdef CONFIG_CMA_AGGRESSIVE
> + if (cma_aggressive_switch
> + && migratetype == MIGRATE_MOVABLE
> + && atomic_read(_alloc_counter) == 0
> + && global_page_state(NR_FREE_CMA_PAGES) > cma_aggressive_free_min
> + + (1 << order))
> + migratetype = MIGRATE_CMA;
> +#endif
> +retry:
I don't get it why cma_alloc_counter should be tested.
When cma alloc is progress, pageblock is isolated so that pages on that
pageblock cannot be allocated. Why should we prevent aggressive
allocation in this case?
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] futex: fix a race condition between REQUEUE_PI and task death
(CCs more eyeballs) On Thu, 2014-10-23 at 15:28 -0400, Brian Silverman wrote: > Here's the test code: Which took a 2 socket 28 core box (NOPREEMPT) out in short order. With patchlet applied, looks like it'll stay up (37 minutes and counting), I'll squeak if it explodes. Tested-by: Mike Galbraith [ 387.396020] BUG: unable to handle kernel NULL pointer dereference at 0b34 [ 387.414177] IP: [] free_pi_state+0x4e/0xb0 [ 387.427638] PGD 8394fe067 PUD 847c37067 PMD 0 [ 387.438457] Oops: 0002 [#1] SMP [ 387.446534] Modules linked in: nfs(E) lockd(E) grace(E) sunrpc(E) fscache(E) iscsi_ibft(E) iscsi_boot_sysfs(E) af_packet(E) ext4(E) crc16(E) mbcache(E) jbd2(E) joydev(E) hid_generic(E) intel_rapl(E) usbhid(E) x86_pkg_temp_thermal(E) iTCO_wdt(E) intel_powerclamp(E) iTCO_vendor_support(E) coretemp(E) kvm_intel(E) kvm(E) crct10dif_pclmul(E) crc32_pclmul(E) ghash_clmulni_intel(E) aesni_intel(E) aes_x86_64(E) lrw(E) ixgbe(E) gf128mul(E) glue_helper(E) ptp(E) ablk_helper(E) pps_core(E) cryptd(E) sb_edac(E) pcspkr(E) mdio(E) edac_core(E) ipmi_si(E) dca(E) ipmi_msghandler(E) lpc_ich(E) mfd_core(E) wmi(E) acpi_power_meter(E) xhci_pci(E) mei_me(E) i2c_i801(E) acpi_pad(E) processor(E) mei(E) xhci_hcd(E) shpchp(E) button(E) dm_mod(E) btrfs(E) xor(E) raid6_pq(E) sr_mod(E) cdrom(E) sd_mod(E) mgag200(E) syscopyarea(E) [ 387.610406] sysfillrect(E) sysimgblt(E) i2c_algo_bit(E) drm_kms_helper(E) ehci_pci(E) ttm(E) ahci(E) ehci_hcd(E) crc32c_intel(E) libahci(E) drm(E) usbcore(E) libata(E) usb_common(E) sg(E) scsi_mod(E) autofs4(E) [ 387.651513] CPU: 27 PID: 136696 Comm: futex-exit-race Tainted: G E 3.18.0-default #51 [ 387.672339] Hardware name: Intel Corporation S2600WTT/S2600WTT, BIOS GRNDSDP1.86B.0030.R03.1405061547 05/06/2014 [ 387.696066] task: 880833002250 ti: 880830d04000 task.ti: 880830d04000 [ 387.713855] RIP: 0010:[] [] free_pi_state+0x4e/0xb0 [ 387.733015] RSP: 0018:880830d07d78 EFLAGS: 00010046 [ 387.746030] RAX: RBX: 8804592ea340 RCX: 0bb6 [ 387.763089] RDX: 8804592ea340 RSI: 880866c3fb48 RDI: 88083b40cb84 [ 387.780167] RBP: 880830d07d88 R08: c900136b8a70 R09: 88046afe8150 [ 387.797255] R10: R11: 000101b0 R12: 880830d07e08 [ 387.814360] R13: R14: c900136b8a70 R15: 0001 [ 387.831476] FS: 7fb2637c5700() GS:88087f1a() knlGS: [ 387.850710] CS: 0010 DS: ES: CR0: 80050033 [ 387.864766] CR2: 0b34 CR3: 0008374e7000 CR4: 001407e0 [ 387.881901] Stack: [ 387.887707] 880830d07d88 880830d07e58 810d52c4 [ 387.905497] 001b0001 880830d07e20 0002018230d07dc8 0001 [ 387.923290] c900136b8a84 880830d07f08 7fb2637d838c 00010001 [ 387.941071] Call Trace: [ 387.947864] [] futex_requeue+0x2b4/0x8e0 [ 387.961578] [] do_futex+0xa9/0x580 [ 387.974128] [] ? do_nanosleep+0x82/0x110 [ 387.987814] [] ? hrtimer_nanosleep+0xac/0x160 [ 388.002458] [] SyS_futex+0x71/0x150 [ 388.015181] [] system_call_fastpath+0x12/0x17 [ 388.029826] Code: 30 48 85 ff 74 41 48 81 c7 34 0b 00 00 e8 7b 1f 4b 00 48 8b 43 08 48 8b 13 48 89 42 08 48 89 10 48 89 1b 48 89 5b 08 48 8b 43 30 <66> 83 80 34 0b 00 00 01 fb 66 0f 1f 44 00 00 48 8b 73 30 48 8d [ 388.075136] RIP [] free_pi_state+0x4e/0xb0 [ 388.089266] RSP [ 388.098386] CR2: 0b34 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation
On Thu, Oct 16, 2014 at 11:35:47AM +0800, Hui Zhu wrote: > In fallbacks of page_alloc.c, MIGRATE_CMA is the fallback of > MIGRATE_MOVABLE. > MIGRATE_MOVABLE will use MIGRATE_CMA when it doesn't have a page in > order that Linux kernel want. > > If a system that has a lot of user space program is running, for > instance, an Android board, most of memory is in MIGRATE_MOVABLE and > allocated. Before function __rmqueue_fallback get memory from > MIGRATE_CMA, the oom_killer will kill a task to release memory when > kernel want get MIGRATE_UNMOVABLE memory because fallbacks of > MIGRATE_UNMOVABLE are MIGRATE_RECLAIMABLE and MIGRATE_MOVABLE. > This status is odd. The MIGRATE_CMA has a lot free memory but Linux > kernel kill some tasks to release memory. > > This patch series adds a new function CMA_AGGRESSIVE to make CMA memory > be more aggressive about allocation. > If function CMA_AGGRESSIVE is available, when Linux kernel call function > __rmqueue try to get pages from MIGRATE_MOVABLE and conditions allow, > MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first. If MIGRATE_CMA > doesn't have enough pages for allocation, go back to allocate memory from > MIGRATE_MOVABLE. > Then the memory of MIGRATE_MOVABLE can be kept for MIGRATE_UNMOVABLE and > MIGRATE_RECLAIMABLE which doesn't have fallback MIGRATE_CMA. Hello, I did some work similar to this. Please reference following links. https://lkml.org/lkml/2014/5/28/64 https://lkml.org/lkml/2014/5/28/57 And, aggressive allocation should be postponed until freepage counting bug is fixed, because aggressive allocation enlarge the possiblity of problem occurence. I tried to fix that bug, too. See following link. https://lkml.org/lkml/2014/10/23/90 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 03/16] perf session: Add perf_session__deliver_synth_event()
On Thu, 23 Oct 2014 13:45:11 +0300, Adrian Hunter wrote:
> Add a function to deliver synthesized events from
> within a session.
>
> Signed-off-by: Adrian Hunter
> ---
> tools/perf/util/session.c | 14 ++
> tools/perf/util/session.h | 5 +
> 2 files changed, 19 insertions(+)
>
> diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
> index d70e37d..09635d1 100644
> --- a/tools/perf/util/session.c
> +++ b/tools/perf/util/session.c
> @@ -907,6 +907,20 @@ static s64 perf_session__process_user_event(struct
> perf_session *session,
> }
> }
>
> +int perf_session__deliver_synth_event(struct perf_session *session,
> + union perf_event *event,
> + struct perf_sample *sample,
> + struct perf_tool *tool)
> +{
> + events_stats__inc(>stats, event->header.type);
> +
> + if (event->header.type >= PERF_RECORD_USER_TYPE_START)
> + return perf_session__process_user_event(session, event, tool,
> + 0);
> +
> + return perf_session__deliver_event(session, event, sample, tool, 0);
> +}
It seems that it's basically same as what perf_session__process_event()
does. So it might deserve a comment or better changelog why it's needed.
Thanks,
Namhyung
> +
> static void event_swap(union perf_event *event, bool sample_id_all)
> {
> perf_event__swap_op swap;
> diff --git a/tools/perf/util/session.h b/tools/perf/util/session.h
> index d8521ac..dc26ebf 100644
> --- a/tools/perf/util/session.h
> +++ b/tools/perf/util/session.h
> @@ -127,6 +127,11 @@ extern volatile int session_done;
>
> #define session_done() ACCESS_ONCE(session_done)
>
> +int perf_session__deliver_synth_event(struct perf_session *session,
> + union perf_event *event,
> + struct perf_sample *sample,
> + struct perf_tool *tool);
> +
> int perf_event__process_id_index(struct perf_tool *tool,
>union perf_event *event,
>struct perf_session *session);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/16] perf pmu: Let pmu's with no events show up on perf list
On Thu, 23 Oct 2014 13:45:10 +0300, Adrian Hunter wrote:
> perf list only lists PMUs with events. Add a
> flag to cause a PMU to be also listed separately.
>
> Signed-off-by: Adrian Hunter
> ---
> tools/perf/util/pmu.c | 13 +++--
> tools/perf/util/pmu.h | 1 +
> 2 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
> index e243ad9..91dca60 100644
> --- a/tools/perf/util/pmu.c
> +++ b/tools/perf/util/pmu.c
> @@ -747,15 +747,18 @@ void print_pmu_events(const char *event_glob, bool
> name_only)
>
> pmu = NULL;
> len = 0;
> - while ((pmu = perf_pmu__scan(pmu)) != NULL)
> + while ((pmu = perf_pmu__scan(pmu)) != NULL) {
> list_for_each_entry(alias, >aliases, list)
> len++;
> + if (pmu->selectable)
> + len++;
> + }
> aliases = malloc(sizeof(char *) * len);
> if (!aliases)
> return;
> pmu = NULL;
> j = 0;
> - while ((pmu = perf_pmu__scan(pmu)) != NULL)
> + while ((pmu = perf_pmu__scan(pmu)) != NULL) {
> list_for_each_entry(alias, >aliases, list) {
> char *name = format_alias(buf, sizeof(buf), pmu, alias);
> bool is_cpu = !strcmp(pmu->name, "cpu");
> @@ -772,6 +775,12 @@ void print_pmu_events(const char *event_glob, bool
> name_only)
> aliases[j] = strdup(aliases[j]);
> j++;
> }
> + if (pmu->selectable) {
> + scnprintf(buf, sizeof(buf), "%s//", pmu->name);
> + aliases[j] = strdup(buf);
You need to check the return value here (and above too).
> + j++;
> + }
> + }
> len = j;
> qsort(aliases, len, sizeof(char *), cmp_string);
> for (j = 0; j < len; j++) {
> diff --git a/tools/perf/util/pmu.h b/tools/perf/util/pmu.h
> index fe9dfbe..8092de7 100644
> --- a/tools/perf/util/pmu.h
> +++ b/tools/perf/util/pmu.h
> @@ -18,6 +18,7 @@ struct perf_event_attr;
> struct perf_pmu {
> char *name;
> __u32 type;
> + bool selectable;
I think it's a bit confusing. IIUC this 'selectable' means that this
PMU doesn't contain any events but wants to be listed. So the normal
PMUs which contain events are not selectable, right?
Thanks,
Namhyung
> struct perf_event_attr *default_config;
> struct cpu_map *cpus;
> struct list_head format; /* HEAD struct perf_pmu_format -> list */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/16] perf tools: Add id index
On Thu, 23 Oct 2014 18:08:17 -0300, Arnaldo Carvalho de Melo wrote: > Em Thu, Oct 23, 2014 at 01:45:09PM +0300, Adrian Hunter escreveu: >> Add an index of the event identifiers. >> >> This is needed to queue Instruction >> Trace samples according to the mmap >> buffer from which they were recorded. > > This gets difficult to review, I end up having to look at all the > patches together to figure out the use cases, to see if this here makes > sense... > > Can you try to explain like to a seven year old? > > Sigh. > > 'id' is somethig super vague, what does this identifies? I want to make > progress processing these patches, but with so short explanations like > the above one, it gets difficult. I also often get confused when I saw an id and/or idx. ;-) 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/
[PATCH RFC] arm/arm64:add CONFIG_HAVE_ARCH_BITREVERSE to support rbit
this change add CONFIG_HAVE_ARCH_BITREVERSE config option,
so that we can use arm/arm64 rbit instruction to do bitrev operation
by hardware.
Signed-off-by: Yalin Wang
---
arch/arm/Kconfig| 1 +
arch/arm/include/asm/bitrev.h | 21 +
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/bitrev.h | 21 +
include/linux/bitrev.h | 9 +
lib/Kconfig | 8
lib/bitrev.c| 2 ++
7 files changed, 63 insertions(+)
create mode 100644 arch/arm/include/asm/bitrev.h
create mode 100644 arch/arm64/include/asm/bitrev.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 89c4b5c..426cbcc 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -16,6 +16,7 @@ config ARM
select DCACHE_WORD_ACCESS if HAVE_EFFICIENT_UNALIGNED_ACCESS
select GENERIC_ALLOCATOR
select GENERIC_ATOMIC64 if (CPU_V7M || CPU_V6 || !CPU_32v6K || !AEABI)
+ select HAVE_ARCH_BITREVERSE if (CPU_V7M || CPU_V7)
select GENERIC_CLOCKEVENTS_BROADCAST if SMP
select GENERIC_IDLE_POLL_SETUP
select GENERIC_IRQ_PROBE
diff --git a/arch/arm/include/asm/bitrev.h b/arch/arm/include/asm/bitrev.h
new file mode 100644
index 000..0df5866
--- /dev/null
+++ b/arch/arm/include/asm/bitrev.h
@@ -0,0 +1,21 @@
+#ifndef __ASM_ARM_BITREV_H
+#define __ASM_ARM_BITREV_H
+
+static inline __attribute_const__ u32 __arch_bitrev32(u32 x)
+{
+ __asm__ ("rbit %0, %1" : "=r" (x) : "r" (x));
+ return x;
+}
+
+static inline __attribute_const__ u16 __arch_bitrev16(u16 x)
+{
+ return __arch_bitrev32((u32)x) >> 16;
+}
+
+static inline __attribute_const__ u8 __arch_bitrev8(u8 x)
+{
+ return __arch_bitrev32((u32)x) >> 24;
+}
+
+#endif
+
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index ac9afde..a2566d7 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -35,6 +35,7 @@ config ARM64
select HARDIRQS_SW_RESEND
select HAVE_ARCH_AUDITSYSCALL
select HAVE_ARCH_JUMP_LABEL
+ select HAVE_ARCH_BITREVERSE
select HAVE_ARCH_KGDB
select HAVE_ARCH_TRACEHOOK
select HAVE_BPF_JIT
diff --git a/arch/arm64/include/asm/bitrev.h b/arch/arm64/include/asm/bitrev.h
new file mode 100644
index 000..5d24c11
--- /dev/null
+++ b/arch/arm64/include/asm/bitrev.h
@@ -0,0 +1,21 @@
+#ifndef __ASM_ARM_BITREV_H
+#define __ASM_ARM_BITREV_H
+
+static inline __attribute_const__ u32 __arch_bitrev32(u32 x)
+{
+ __asm__ ("rbit %w0, %w1" : "=r" (x) : "r" (x));
+ return x;
+}
+
+static inline __attribute_const__ u16 __arch_bitrev16(u16 x)
+{
+ return __arch_bitrev32((u32)x) >> 16;
+}
+
+static inline __attribute_const__ u8 __arch_bitrev8(u8 x)
+{
+ return __arch_bitrev32((u32)x) >> 24;
+}
+
+#endif
+
diff --git a/include/linux/bitrev.h b/include/linux/bitrev.h
index 7ffe03f..ef5b2bb 100644
--- a/include/linux/bitrev.h
+++ b/include/linux/bitrev.h
@@ -3,6 +3,14 @@
#include
+#ifdef CONFIG_HAVE_ARCH_BITREVERSE
+#include
+
+#define bitrev32 __arch_bitrev32
+#define bitrev16 __arch_bitrev16
+#define bitrev8 __arch_bitrev8
+
+#else
extern u8 const byte_rev_table[256];
static inline u8 bitrev8(u8 byte)
@@ -13,4 +21,5 @@ static inline u8 bitrev8(u8 byte)
extern u16 bitrev16(u16 in);
extern u32 bitrev32(u32 in);
+#endif /* CONFIG_HAVE_ARCH_BITREVERSE */
#endif /* _LINUX_BITREV_H */
diff --git a/lib/Kconfig b/lib/Kconfig
index 54cf309..e0e0453 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -13,6 +13,14 @@ config RAID6_PQ
config BITREVERSE
tristate
+config HAVE_ARCH_BITREVERSE
+ boolean
+ default n
+ help
+ This option provides an config for the architecture which have
instruction
+ can do bitreverse operation, we use the hardware instruction if the
architecture
+ have this capability.
+
config RATIONAL
boolean
diff --git a/lib/bitrev.c b/lib/bitrev.c
index 3956203..93d637a 100644
--- a/lib/bitrev.c
+++ b/lib/bitrev.c
@@ -1,3 +1,4 @@
+#ifndef CONFIG_HAVE_ARCH_BITREVERSE
#include
#include
#include
@@ -57,3 +58,4 @@ u32 bitrev32(u32 x)
return (bitrev16(x & 0x) << 16) | bitrev16(x >> 16);
}
EXPORT_SYMBOL(bitrev32);
+#endif /* CONFIG_HAVE_ARCH_BITREVERSE */
--
2.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/14] net: dsa: Add support for hardware monitoring
From: Guenter Roeck Date: Wed, 22 Oct 2014 22:06:41 -0700 > On 10/22/2014 09:37 PM, Florian Fainelli wrote: >> 2014-10-22 21:03 GMT-07:00 Guenter Roeck : >>> Some Marvell switches provide chip temperature data. >>> Add support for reporting it to the dsa infrastructure. >>> >>> Signed-off-by: Guenter Roeck >>> --- >> [snip] >> >>> +/* hwmon support >>> / >>> + >>> +#if defined(CONFIG_HWMON) || (defined(MODULE) && >>> defined(CONFIG_HWMON_MODULE)) >> >> IS_ENABLED(CONFIG_HWMON)? >> > > Hi Florian, > > unfortunately, that won't work; I had it initially and got a nice > error message > from Fengguang's build test bot. Then the Kconfig dependencies are broken. Fix Kconfig to only allow legal combinations. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] staging: android: binder: move to the "real" part of the kernel
On Tue, Oct 21, 2014 at 08:10:32PM -0700, Rom Lemarchand wrote: > We would also like to make kernel-t...@android.com the maintainer of > the whole android directory. Mailing lists can't be a maintainer, but you could add it as a private list in the MAINTAINERS file. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/4] [RFC] slub: Fastpath optimization (especially for RT)
On Thu, Oct 23, 2014 at 09:18:29AM -0500, Christoph Lameter wrote: > On Thu, 23 Oct 2014, Joonsoo Kim wrote: > > > Preemption disable during very short code would cause large problem for RT? > > This is the hotpath and preempt enable/disable adds a significant number > of cycles. > > > And, if page_address() and virt_to_head_page() remain as current patchset > > implementation, this would work worse than before. > > Right. > > > I looked at the patchset quickly and found another idea to remove > > preemption disable. How about just retrieving s->cpu_slab->tid first, > > before accessing s->cpu_slab, in slab_alloc() and slab_free()? > > Retrieved tid may ensure that we aren't migrated to other CPUs so that > > we can remove code for preemption disable. > > You cannot do any of these things because you need the tid from the right > cpu and the scheduler can prempt you and reschedule you on another > processor at will. tid and c may be from different per cpu areas. I found that you said retrieving tid first is sufficient to do things right in old discussion. :) https://lkml.org/lkml/2013/1/18/430 Think about following 4 examples. TID CPU_CACHE CMPX_DOUBLE 1. cpu0 cpu0 cpu0 2. cpu0 cpu0 cpu1 3. cpu0 cpu1 cpu0 4. cpu0 cpu1 cpu1 1) has no problem and will succeed. 2, 4) would be failed due to tid mismatch. Only complicated case is scenario 3). In this case, object from cpu1's cpu_cache should be different with cpu0's, so allocation would be failed. Only problem of this method is that it's not easy to understand. Am I missing something? 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: unaligned accesses in SLAB etc.
A minor detail. > [PATCH] sparc64: Fix register corruption in top-most kernel stack frame > during boot. > > - callstart_kernel > + call start_early_boot Maybe add a comment about stack use - as per your nice patch description. > +void __init start_early_boot(void) This will likely result in sparse complaining about: fuction not declared - should it be static? A prototype in include/asm/setup.h would be nice. Other than this - very nice detective work! Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 1/2] staging: skein: Adds CryptoAPI Support
First of all this patch does too many things at once. Collapsing files
and deleting them needs to be done in separate patches from adding them.
There is the "one thing per patch" and each one of those is a separate
thing.
On Thu, Oct 23, 2014 at 05:12:10PM -0500, Eric Rost wrote:
> +int skein256_update(struct shash_desc *desc, const u8 *data,
> + unsigned int len)
> +{
> + return skein_256_update((struct skein_256_ctx *) shash_desc_ctx(desc),
> + data, (size_t) len);
> +}
The two line version of this cast was prettier. Also if you run
checkpatch.pl --strict over this it will hopefully warn about the
space in the middle of the cast and the alignment of data. Also the
cast to size_t is superflous.
The checkpatch --strict version of this looks like:
int skein256_update(struct shash_desc *desc, const u8 *data,
unsigned int len)
{
return skein_256_update((struct skein_256_ctx *)shash_desc_ctx(desc),
data, len);
}
Eventually, I feel like we would wave skein_256_update() to just take
a shash_desc pointer? We'd have to shuffle the skein_ctx struct a bit
to make that work. (I haven't looked at this carefully).
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: localed stuck in recent 3.18 git in copy_net_ns?
Paul E. McKenney wrote: >On Fri, Oct 24, 2014 at 12:45:40AM +0300, Yanko Kaneti wrote: >> >> On Thu, 2014-10-23 at 13:05 -0700, Paul E. McKenney wrote: >> > On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote: >> > > On Thu-10/23/14-2014 08:33, Paul E. McKenney wrote: >> > > > On Thu, Oct 23, 2014 at 05:27:50AM -0700, Paul E. McKenney wrote: >> > > > > On Thu, Oct 23, 2014 at 09:09:26AM +0300, Yanko Kaneti wrote: >> > > > > > On Wed, 2014-10-22 at 16:24 -0700, Paul E. McKenney wrote: >> > > > > > > On Thu, Oct 23, 2014 at 01:40:32AM +0300, Yanko Kaneti >> > > > > > > wrote: >> > > > > > > > On Wed-10/22/14-2014 15:33, Josh Boyer wrote: >> > > > > > > > > On Wed, Oct 22, 2014 at 2:55 PM, Paul E. McKenney >> > > > > > > > > wrote: >> > > > > > > >> > > > > > > [ . . . ] >> > > > > > > >> > > > > > > > > > Don't get me wrong -- the fact that this kthread >> > > > > > > > > > appears to >> > > > > > > > > > have >> > > > > > > > > > blocked within rcu_barrier() for 120 seconds means >> > > > > > > > > > that >> > > > > > > > > > something is >> > > > > > > > > > most definitely wrong here. I am surprised that >> > > > > > > > > > there are no >> > > > > > > > > > RCU CPU >> > > > > > > > > > stall warnings, but perhaps the blockage is in the >> > > > > > > > > > callback >> > > > > > > > > > execution >> > > > > > > > > > rather than grace-period completion. Or something is >> > > > > > > > > > preventing this >> > > > > > > > > > kthread from starting up after the wake-up callback >> > > > > > > > > > executes. >> > > > > > > > > > Or... >> > > > > > > > > > >> > > > > > > > > > Is this thing reproducible? >> > > > > > > > > >> > > > > > > > > I've added Yanko on CC, who reported the backtrace >> > > > > > > > > above and can >> > > > > > > > > recreate it reliably. Apparently reverting the RCU >> > > > > > > > > merge commit >> > > > > > > > > (d6dd50e) and rebuilding the latest after that does >> > > > > > > > > not show the >> > > > > > > > > issue. I'll let Yanko explain more and answer any >> > > > > > > > > questions you >> > > > > > > > > have. >> > > > > > > > >> > > > > > > > - It is reproducible >> > > > > > > > - I've done another build here to double check and its >> > > > > > > > definitely >> > > > > > > > the rcu merge >> > > > > > > > that's causing it. >> > > > > > > > >> > > > > > > > Don't think I'll be able to dig deeper, but I can do >> > > > > > > > testing if >> > > > > > > > needed. >> > > > > > > >> > > > > > > Please! Does the following patch help? >> > > > > > >> > > > > > Nope, doesn't seem to make a difference to the modprobe >> > > > > > ppp_generic >> > > > > > test >> > > > > >> > > > > Well, I was hoping. I will take a closer look at the RCU >> > > > > merge commit >> > > > > and see what suggests itself. I am likely to ask you to >> > > > > revert specific >> > > > > commits, if that works for you. >> > > > >> > > > Well, rather than reverting commits, could you please try >> > > > testing the >> > > > following commits? >> > > > >> > > > 11ed7f934cb8 (rcu: Make nocb leader kthreads process pending >> > > > callbacks after spawning) >> > > > >> > > > 73a860cd58a1 (rcu: Replace flush_signals() with >> > > > WARN_ON(signal_pending())) >> > > > >> > > > c847f14217d5 (rcu: Avoid misordering in nocb_leader_wait()) >> > > > >> > > > For whatever it is worth, I am guessing this one. >> > > >> > > Indeed, c847f14217d5 it is. >> > > >> > > Much to my embarrasment I just noticed that in addition to the >> > > rcu merge, triggering the bug "requires" my specific Fedora >> > > rawhide network >> > > setup. Booting in single mode and modprobe ppp_generic is fine. >> > > The bug >> > > appears when starting with my regular fedora network setup, which >> > > in my case >> > > includes 3 ethernet adapters and a libvirt birdge+nat setup. >> > > >> > > Hope that helps. >> > > >> > > I am attaching the config. >> > >> > It does help a lot, thank you!!! >> > >> > The following patch is a bit of a shot in the dark, and assumes that >> > commit 1772947bd012 (rcu: Handle NOCB callbacks from irq-disabled >> > idle >> > code) introduced the problem. Does this patch fix things up? >> >> Unfortunately not, This is linus-tip + patch > >OK. Can't have everything, I guess. > >> INFO: task kworker/u16:6:96 blocked for more than 120 seconds. >> Not tainted 3.18.0-rc1+ #4 >> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. >> kworker/u16:6 D 8800ca84cec0 1116896 2 0x >> Workqueue: netns cleanup_net >> 8802218339e8 0096 8800ca84cec0 001d5f00 >> 880221833fd8 001d5f00 880223264ec0 8800ca84cec0 >> 82c52040 7fff 81ee2658 81ee2650 >> Call Trace: >> [] schedule+0x29/0x70 >> [] schedule_timeout+0x26c/0x410 >> [] ? native_sched_clock+0x2a/0xa0 >> [] ? mark_held_locks+0x7c/0xb0 >> [] ?
Re: [PATCH v4 4/6] ARM: rockchip: add suspend and resume for RK3288
Chris,
On Tue, Oct 21, 2014 at 4:25 PM, Chris Zhong wrote:
> +static inline void rk3288_copy_data_to_sram(void)
> +{
> + u32 resume_code_size = (u32)_bootdata_cpu_code -
> + (u32)rockchip_slp_cpu_resume + 4;
> +
> + /* save root sram data in ddr mem */
> + memcpy(rk3288_bootram_base, bootram_save_data, SZ_4K);
I swore we looked at this before, but the above memcpy is backwards.
> + /* move resume code and data to bootsram */
> + memcpy(rk3288_bootram_base, rockchip_slp_cpu_resume,
> + resume_code_size);
> +}
> +
> +static inline void rk3288_restore_original_sram(void)
> +{
> + memcpy(bootram_save_data, rk3288_bootram_base, SZ_4K);
This one too.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cirrus/mac89x0: Remove superfluous interrupt disable/restore
From: Geert Uytterhoeven
Date: Tue, 21 Oct 2014 19:53:11 +0200
> As of commit e4dc601bf99ccd1c ("m68k: Disable/restore interrupts in
> hwreg_present()/hwreg_write()"), this is no longer needed.
>
> Signed-off-by: Geert Uytterhoeven
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] natsemi/macsonic: Remove superfluous interrupt disable/restore
From: Geert Uytterhoeven
Date: Tue, 21 Oct 2014 19:53:57 +0200
> As of commit e4dc601bf99ccd1c ("m68k: Disable/restore interrupts in
> hwreg_present()/hwreg_write()"), this is no longer needed.
>
> Signed-off-by: Geert Uytterhoeven
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: typhoon: Remove redundant casts
From: Rasmus Villemoes Date: Tue, 21 Oct 2014 16:51:43 +0200 > Both image_data and typhoon_fw->data are const u8*, so the cast to u8* > is unnecessary and confusing. > > Signed-off-by: Rasmus Villemoes Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Please Resend Your Message.
I, Liliane authenticate this email to you. You can read about me on: fr.wikipedia.org/wiki/Liliane_Bettencourt I intend to give to you a portion of my Net-worth which I have been banking. Click reply for confirmation and more details. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] time: Complete NTP adjustment threshold judging conditions
On Thu, Oct 9, 2014 at 12:04 AM, pang.xunlei wrote: > The clocksource mult-adjustment threshold is [mult-maxadj, mult+maxadj], > timekeeping_adjust() only deals with the upper threshold, but misses the > lower threshold. > > This patch adds the lower threshold judging condition. > > Signed-off-by: pang.xunlei Added to my 3.19 queue. thanks! -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] time: Fix NTP adjustment mult overflow.
On Wed, Oct 22, 2014 at 5:37 AM, Xunlei Pang wrote: > The mult memember of struct clocksource should always be a large u32 number > when calculated through > __clocksource_updatefreq_scale(). The value of (cs->mult+cs->maxadj) may > have a chance to reach very > near 0x, so it may overflow when doing NTP positive adjustment, see > the following detail: > When NTP slewes the clock, kernel goes through > update_wall_time()->...->timekeeping_apply_adjustment(): > tk->tkr.mult += mult_adj; > Unfortunately, tk->tkr.mult may overflow after this operation. > > > This patch avoids mult overflow by judging the overflow case before adding > mult_adj to mult, also adds the > WARNING message when capturing such case. > > Signed-off-by: pang.xunlei I reworded this a bit further, but its in my queue for 3.19. thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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-next] net: phy: Adding SGMII support for Marvell 88ee1145 driver
From: Viet Nga Dao
Additional code to m88e1145_config_init function to allow the driver to
support SGMII mode.
Signed-off-by: Viet Nga Dao
---
drivers/net/phy/marvell.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index bd37e45..b14cb10 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -50,9 +50,13 @@
#define MII_M1011_PHY_SCR 0x10
#define MII_M1011_PHY_SCR_AUTO_CROSS 0x0060
+#define MII_M1145_PHY_EXT_SR 0x1b
#define MII_M1145_PHY_EXT_CR 0x14
#define MII_M1145_RGMII_RX_DELAY 0x0080
#define MII_M1145_RGMII_TX_DELAY 0x0002
+#define MII_M1145_HWCFG_MODE_SGMII_NO_CLK 0x4
+#define MII_M1145_HWCFG_MODE_MASK 0xf
+#define MII_M1145_HWCFG_FIBER_COPPER_AUTO 0x8000
#define MII_M_PHY_LED_CONTROL 0x18
#define MII_M_PHY_LED_DIRECT 0x4100
@@ -620,6 +624,7 @@ static int m88e1149_config_init(struct phy_device *phydev)
static int m88e1145_config_init(struct phy_device *phydev)
{
int err;
+ int temp;
/* Take care of errata E0 & E1 */
err = phy_write(phydev, 0x1d, 0x001b);
@@ -676,6 +681,20 @@ static int m88e1145_config_init(struct phy_device *phydev)
}
}
+ if (phydev->interface == PHY_INTERFACE_MODE_SGMII) {
+ temp = phy_read(phydev, MII_M1145_PHY_EXT_SR);
+ if (temp < 0)
+ return temp;
+
+ temp &= ~(MII_M1145_HWCFG_MODE_MASK);
+ temp |= MII_M1145_HWCFG_MODE_SGMII_NO_CLK;
+ temp |= MII_M1145_HWCFG_FIBER_COPPER_AUTO;
+
+ err = phy_write(phydev, MII_M1145_PHY_EXT_SR, temp);
+ if (err < 0)
+ return err;
+ }
+
err = marvell_of_reg_init(phydev);
if (err < 0)
return err;
--
1.7.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: Remove trailing whitespace in tcp.h icmp.c syncookies.c
From: Kenjiro Nakayama Date: Mon, 20 Oct 2014 18:15:50 +0900 > Remove trailing whitespace in tcp.h icmp.c syncookies.c > > Signed-off-by: Kenjiro Nakayama Applied -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 PATCH V3 0/3] x86: Full support of PAT
Ping? On 10/20/2014 05:59 AM, Juergen Gross wrote: Hi x86 maintainers, any reason you seem to ignore this patch series? I think I've replied to all open issues and sent the patches more than one month ago. Each patch has a "Reviewed-by". Is there something else missing? Juergen On 10/13/2014 10:13 AM, Juergen Gross wrote: The x86 architecture offers via the PAT (Page Attribute Table) a way to specify different caching modes in page table entries. The PAT MSR contains 8 entries each specifying one of 6 possible cache modes. A pte references one of those entries via 3 bits: _PAGE_PAT, _PAGE_PWT and _PAGE_PCD. The Linux kernel currently supports only 4 different cache modes. The PAT MSR is set up in a way that the setting of _PAGE_PAT in a pte doesn't matter: the top 4 entries in the PAT MSR are the same as the 4 lower entries. This results in the kernel not supporting e.g. write-through mode. Especially this cache mode would speed up drivers of video cards which now have to use uncached accesses. OTOH some old processors (Pentium) don't support PAT correctly and the Xen hypervisor has been using a different PAT MSR configuration for some time now and can't change that as this setting is part of the ABI. This patch set abstracts the cache mode from the pte and introduces tables to translate between cache mode and pte bits (the default cache mode "write back" is hard-wired to PAT entry 0). The tables are statically initialized with values being compatible to old processors and current usage. As soon as the PAT MSR is changed (or - in case of Xen - is read at boot time) the tables are changed accordingly. Requests of mappings with special cache modes are always possible now, in case they are not supported there will be a fallback to a compatible but slower mode. Summing it up, this patch set adds the following features: - capability to support WT and WP cache modes on processors with full PAT support - processors with no or uncorrect PAT support are still working as today, even if WT or WP cache mode are selected by drivers for some pages - reduction of Xen special handling regarding cache mode Changes in V3: - corrected two minor nits (UC_MINUS, again) detected by Toshi Kani Changes in V2: - simplified handling of PAT MSR write under Xen as suggested by David Vrabel - removed resetting of pat_enabled under Xen - two small corrections requested by Toshi Kani (UC_MINUS cache mode in vermilion driver, fix 32 bit kernel build failure) - correct build error on non-x86 arch by moving definition of update_cache_mode_entry() to x86 specific header Changes since RFC: - renamed functions and variables as suggested by Toshi Kani - corrected cache mode bits for WT and WP - modified handling of PAT MSR write under Xen as suggested by Jan Beulich Juergen Gross (3): x86: Make page cache mode a real type x86: Enable PAT to use cache mode translation tables Support Xen pv-domains using PAT arch/x86/include/asm/cacheflush.h | 38 --- arch/x86/include/asm/fb.h | 6 +- arch/x86/include/asm/io.h | 2 +- arch/x86/include/asm/pat.h| 7 +- arch/x86/include/asm/pgtable.h| 19 ++-- arch/x86/include/asm/pgtable_types.h | 96 arch/x86/mm/dump_pagetables.c | 24 ++-- arch/x86/mm/init.c| 37 ++ arch/x86/mm/init_64.c | 9 +- arch/x86/mm/iomap_32.c| 15 ++- arch/x86/mm/ioremap.c | 63 ++- arch/x86/mm/mm_internal.h | 2 + arch/x86/mm/pageattr.c| 84 -- arch/x86/mm/pat.c | 181 +++--- arch/x86/mm/pat_internal.h| 22 ++-- arch/x86/mm/pat_rbtree.c | 8 +- arch/x86/pci/i386.c | 4 +- arch/x86/xen/enlighten.c | 25 ++--- arch/x86/xen/mmu.c| 48 +--- arch/x86/xen/xen-ops.h| 1 - drivers/video/fbdev/gbefb.c | 3 +- drivers/video/fbdev/vermilion/vermilion.c | 6 +- 22 files changed, 421 insertions(+), 279 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/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] at91: fixes for 3.18 #1
On Wed, Oct 22, 2014 at 07:01:27PM +0200, Nicolas Ferre wrote: > Arnd, Olof, Kevin, > > This is my first batch of fixes for 3.18. > The power/reset driver part is there because it was introduced through arm-soc > and it seems that it's better to continue like that. > The MAINTAINERS entry is better if included the soonest. > > Note as well that it's my first pull-request from my newly created kernel.org > account: I hope that everything is done properly ;-) > > Thanks, bye, > > The following changes since commit f114040e3ea6e07372334ade75d1ee0775c355e1: > > Linux 3.18-rc1 (2014-10-19 18:08:38 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91.git > tags/at91-fixes > Pulled, thanks. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
netfilter: NAT: do the optimization for getting curr_tuple in function nf_nat_setup_info
Hi all: In function nf_nat_setup_info, we need to get the current tuple which is supposed to send to destination. If we haven't done any NAT (SNAT or DNAT) for the tuple, then the current tuple is equal to original tuple, otherwise, we should get current tuple by invoking nf_ct_invert_tuplepr(curr_tuple, >tuplehash[IP_CT_DIR_REPLY].tuple); like the existing comment says: /* What we've got will look like inverse of reply. Normally * this is what is in the conntrack, except for prior * manipulations (future optimization: if num_manips == 0, * orig_tp = ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple) */ nf_ct_invert_tuplepr(_tuple, >tuplehash[IP_CT_DIR_REPLY].tuple); So, since it is so, why don't we do the optimization for getting current tuple ? As mentioned above, if we have not done DNAT for the tuple, then the current tuple is equal to original tuple. So I add the optimization as following: + if (!(ct->status & IPS_DST_NAT)) /* we do the optimization, as mentioned above */ + curr_tuple = >tuplehash[IP_CT_DIR_ORIGINAL].tuple; + else + nf_ct_invert_tuplepr(curr_tuple, >tuplehash[IP_CT_DIR_REPLY].tuple); the attachment is the detailed diff. do the optimization for getting curr_tuple in function nf_nat_setup_info.diff Description: Binary data
Re: [RFC][PATCH 4/6] SRCU free VMAs
On 10/23/2014 07:03 PM, Peter Zijlstra wrote:
> On Thu, Oct 23, 2014 at 06:14:45PM +0800, Lai Jiangshan wrote:
>>
>>>
>>> +struct vm_area_struct *find_vma_srcu(struct mm_struct *mm, unsigned long
>>> addr)
>>> +{
>>> + struct vm_area_struct *vma;
>>> + unsigned int seq;
>>> +
>>> + WARN_ON_ONCE(!srcu_read_lock_held(_srcu));
>>> +
>>> + do {
>>> + seq = read_seqbegin(>mm_seq);
>>> + vma = __find_vma(mm, addr);
>>
>> will the __find_vma() loops for ever due to the rotations in the RBtree?
>
> No, a rotation takes a tree and generates a tree, furthermore the
> rotation has a fairly strict fwd progress guarantee seeing how its now
> done with preemption disabled.
I can't get the magic.
__find_vma is visiting vma_a,
vma_a is rotated to near the top due to multiple updates to the mm.
__find_vma is visiting down to near the bottom, vma_b.
now vma_b is rotated up to near the top again.
__find_vma is visiting down to near the bottom, vma_c.
now vma_c is rotated up to near the top again.
...
>
> Therefore, even if we're in a node that's being rotated up, we can only
> 'loop' for as long as it takes for the new pointer stores to become
> visible on our CPU.
>
> Thus we have a tree descent termination guarantee.
> .
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 10/14] net: dsa/mv88e6352: Implement EEPROM accessfunctions
On 10/23/2014 11:55 AM, Florian Fainelli wrote:
On 10/23/2014 11:41 AM, Chris Healy wrote:
Hi Guenter,
I do not believe it is possible to know if an EEPROM is attached or not.
If we cannot do this, how about a DT/platform data set of properties
that describes the EEPROM when present?
Yes, I think that is a good idea.
Thanks,
Guenter
Chris
From: Guenter Roeck [li...@roeck-us.net]
Sent: Thursday, October 23, 2014 9:40 AM
To: Andrew Lunn
Cc: net...@vger.kernel.org; David S. Miller; Florian Fainelli;
linux-kernel@vger.kernel.org; Chris Healy
Subject: Re: [PATCH 10/14] net: dsa/mv88e6352: Implement EEPROM
accessfunctions
On Thu, Oct 23, 2014 at 03:54:12PM +0200, Andrew Lunn wrote:
On Wed, Oct 22, 2014 at 09:03:18PM -0700, Guenter Roeck wrote:
MV88E6352 supports read and write access to its configuration eeprom.
Hi Guenter
I don't have the datasheet for the MV88E6352. Is the EEPROM built in,
or external on an i2c bus?
External.
+static int mv88e6352_get_eeprom_len(struct dsa_switch *ds)
+{
+ return 0x200;
+}
How do you handle the case of it being external and not populated.
Would it not be better to try to detect it here, and return 0 if it
does not exist?
Makes sense, if it is detectable that it the EEPROM not there. Browsing
through the datasheet, I don't see how I could detect it; there does not
seem to be a status bit indicating if the EEPROM is there or not. There
are sw_mode pins which determine if the eeprom should be loaded after
reset or not, but I don't see anything in the register set which would
tell me.
Chris, do you know if there is a means to detect if the EEPROM is present
on the MV88E6352 ?
Thanks,
Guenter
This email and any files transmitted with it are confidential & proprietary to
Systems and Software Enterprises, LLC. This information is intended solely for the
use of the individual or entity to which it is addressed. Access or transmittal of
the information contained in this e-mail, in full or in part, to any other
organization or persons is not authorized.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/2] mm: Update generic gup implementation to handle hugepage directory
From: Benjamin Herrenschmidt Date: Fri, 24 Oct 2014 10:40:35 +1100 > Another option would be to make the generic code use something defined > by the arch to decide whether to use speculative get or > not. I like the idea of keeping the bulk of that code generic... Me too. We could have inlines that do either speculative or non-speculative gets on the pages in some header file and hide the ifdefs in there. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ima: check xattr value length in ima_inode_setxattr()
On Fri, 2014-10-24 at 13:55 +1100, James Morris wrote: > On Thu, 23 Oct 2014, Dmitry Kasatkin wrote: > > > ima_inode_setxattr() can be called with no value. Function does not > > check the length so that following command can be used to produce > > kernel oops: setfattr -n security.ima FOO. This patch fixes it. > > I'd like to see more review/acks on this before sending it to Linus. > > Mimi? This fixes the oops, but a more complete solution would at least test the first byte, verifying that it is valid. As previously described http://sourceforge.net/p/linux-ima/mailman/message/32958242/ I think we can do better than this. Mimi > > > -- > James Morris > > > -- > To unsubscribe from this list: send the line "unsubscribe > linux-security-module" 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 V5] mtd: ubi: Extend UBI layer debug/messaging capabilities
On 2014/10/24 11:33, hujianyang wrote:
>
>> @@ -1798,15 +1803,18 @@ int ubi_thread(void *u)
>> int failures = 0;
>> struct ubi_device *ubi = u;
>>
>> -ubi_msg("background thread \"%s\" started, PID %d",
>> +ubi_msg(ubi, "background thread \"%s\" started, PID %d",
>> ubi->bgt_name, task_pid_nr(current));
>>
>> set_freezable();
>> for (;;) {
>> int err;
>>
>> -if (kthread_should_stop())
>> +if (kthread_should_stop()) {
>> +ubi_msg(ubi, "background thread \"%s\" should stop, PID
>> %d",
>> +ubi->bgt_name, task_pid_nr(current));
>> break;
>> +}
>>
>> if (try_to_freeze())
>> continue;
> @@ -470,8 +470,11 @@ struct ubi_wl_entry *ubi_wl_get_fm_peb(struct ubi_device
> *ubi, int anchor)
> {
> struct ubi_wl_entry *e = NULL;
>
> - if (!ubi->free.rb_node || (ubi->free_count - ubi->beb_rsvd_pebs < 1))
> + if (!ubi->free.rb_node || (ubi->free_count - ubi->beb_rsvd_pebs < 1)) {
> + ubi_warn(ubi, "Can't get peb for fastmap:anchor=%d,
> free_cnt=%d, reserved=%d",
> + anchor, ubi->free_count, ubi->beb_rsvd_pebs);
> goto out;
> + }
>
> if (anchor)
> e = find_anchor_wl_entry(>free);
Sorry, one of the adding messages should be this~!
>
>> @@ -1798,15 +1803,18 @@ int ubi_thread(void *u)
>> int failures = 0;
>> struct ubi_device *ubi = u;
>>
>> -ubi_msg("background thread \"%s\" started, PID %d",
>> +ubi_msg(ubi, "background thread \"%s\" started, PID %d",
>> ubi->bgt_name, task_pid_nr(current));
>>
>> set_freezable();
>> for (;;) {
>> int err;
>>
>> -if (kthread_should_stop())
>> +if (kthread_should_stop()) {
>> +ubi_msg(ubi, "background thread \"%s\" should stop, PID
>> %d",
>> +ubi->bgt_name, task_pid_nr(current));
>> break;
>> +}
>>
>> if (try_to_freeze())
>> continue;
>
> Here are two new adding messages. Maybe a separate patch is better? Just a
> suggestion.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V5] mtd: ubi: Extend UBI layer debug/messaging capabilities
Hi Tanya,
When I was trying to push this patch to my product, I reviewed this patch
and found some small problems. I wish it's not too late to report these.
The patch I get from linux-ubifs.git is amended a bit by Artem. I'd like to
quote your V5 patch for simplification. Some line numbers may mismatching.
> @@ -1408,20 +1416,20 @@ static int __init ubi_mtd_param_parse(const char
> *val, struct kernel_param *kp)
> return -EINVAL;
>
> if (mtd_devs == UBI_MAX_DEVICES) {
> - ubi_err("too many parameters, max. is %d\n",
> + pr_err("UBI error: too many parameters, max. is %d\n",
> UBI_MAX_DEVICES);
> return -EINVAL;
> }
>
> len = strnlen(val, MTD_PARAM_LEN_MAX);
> if (len == MTD_PARAM_LEN_MAX) {
> - ubi_err("parameter \"%s\" is too long, max. is %d\n",
> + pr_err("UBI error: parameter \"%s\" is too long, max. is %d\n",
> val, MTD_PARAM_LEN_MAX);
> return -EINVAL;
> }
>
> if (len == 0) {
> - pr_warn("UBI warning: empty 'mtd=' parameter - ignored\n");
> + pr_err("UBI warning: empty 'mtd=' parameter - ignored\n");
> return 0;
> }
Why the last 'pr_warn()' need to be changed into 'pr_err()'? I looked up your
V1 and V2 patches, I think it's not your purpose.
> @@ -176,6 +176,7 @@ static int add_corrupted(struct ubi_attach_info *ai, int
> pnum, int ec)
>
> /**
> * validate_vid_hdr - check volume identifier header.
> + * @ubi: UBI device description object
> * @vid_hdr: the volume identifier header to check
> * @av: information about the volume this logical eraseblock belongs to
> * @pnum: physical eraseblock number the VID header came from
> @@ -48,13 +48,14 @@
>
> /**
> * get_exclusive - get exclusive access to an UBI volume.
> + * @ubi: UBI device description object
> * @desc: volume descriptor
> *
> * This function changes UBI volume open mode to "exclusive". Returns
> previous
> * mode value (positive integer) in case of success and a negative error code
> * in case of failure.
> */
> @@ -660,13 +660,14 @@ static int init_volumes(struct ubi_device *ubi,
>
> /**
> * check_av - check volume attaching information.
> + * @ubi: UBI device description object
> * @vol: UBI volume description object
> * @av: volume attaching information
> *
> * This function returns zero if the volume attaching information is
> consistent
> * to the data read from the volume tabla, and %-EINVAL if not.
> */
> -static int check_av(const struct ubi_volume *vol,
> +static int check_av(const struct ubi_device *ubi, const struct ubi_volume
> *vol,
> const struct ubi_ainf_volume *av)
> {
> int err;
This patch add 'struct ubi_device *' for 3 functions. We can get 'ubi_device'
from
'ubi_volume'. So I think it's because when we call these functions, the '->ubi'
pointer of 'ubi_volume' is not initialized, am I right? This patch use
'vol->ubi'
to indicate a 'struct ubi_device *' pointer in some places, I think you are sure
of using them.
> @@ -1010,28 +1015,28 @@ int ubi_attach_mtd_dev(struct mtd_info *mtd, int
> ubi_num,
> ubi->bgt_thread = kthread_create(ubi_thread, ubi, "%s", ubi->bgt_name);
> if (IS_ERR(ubi->bgt_thread)) {
> err = PTR_ERR(ubi->bgt_thread);
> - ubi_err("cannot spawn \"%s\", error %d", ubi->bgt_name,
> - err);
> + ubi_err(ubi, "cannot spawn \"%s\", error %d",
> + ubi->bgt_name, err);
> goto out_debugfs;
> }
>
> - ubi_msg("attached mtd%d (name \"%s\", size %llu MiB) to ubi%d",
> - mtd->index, mtd->name, ubi->flash_size >> 20, ubi_num);
> - ubi_msg("PEB size: %d bytes (%d KiB), LEB size: %d bytes",
> + ubi_msg(ubi, "attached mtd%d (name \"%s\", size %llu MiB)",
> + mtd->index, mtd->name, ubi->flash_size >> 20);
> + ubi_msg(ubi, "PEB size: %d bytes (%d KiB), LEB size: %d bytes",
> ubi->peb_size, ubi->peb_size >> 10, ubi->leb_size);
We have the parameter 'ubi_num' for log in some functions like
'ubi_attach_mtd_dev'
before. This patch remove 'ubi_num' in upper changes but keep it in other
changes.
Do we have a discussed rule to deal with this situation? It's not a big problem~
> @@ -1798,15 +1803,18 @@ int ubi_thread(void *u)
> int failures = 0;
> struct ubi_device *ubi = u;
>
> - ubi_msg("background thread \"%s\" started, PID %d",
> + ubi_msg(ubi, "background thread \"%s\" started, PID %d",
> ubi->bgt_name, task_pid_nr(current));
>
> set_freezable();
> for (;;) {
> int err;
>
> - if (kthread_should_stop())
> + if (kthread_should_stop()) {
> + ubi_msg(ubi, "background thread \"%s\" should stop, PID
> %d",
> + ubi->bgt_name,
[PATCH] futex: Mention key referencing differences between shared and private futexes
From: Davidlohr Bueso
Update our documentation as of fix 76835b0ebf8 (futex: Ensure
get_futex_key_refs() always implies a barrier). Explicitly
state that we don't do key referencing for private futexes.
Signed-off-by: Davidlohr Bueso
---
kernel/futex.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index f3a3a07..bbf071f 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -143,9 +143,8 @@
*
* Where (A) orders the waiters increment and the futex value read through
* atomic operations (see hb_waiters_inc) and where (B) orders the write
- * to futex and the waiters read -- this is done by the barriers in
- * get_futex_key_refs(), through either ihold or atomic_inc, depending on the
- * futex type.
+ * to futex and the waiters read -- this is done by the barriers for both
+ * shared and private futexes in get_futex_key_refs().
*
* This yields the following case (where X:=waiters, Y:=futex):
*
@@ -344,13 +343,20 @@ static void get_futex_key_refs(union futex_key *key)
futex_get_mm(key); /* implies MB (B) */
break;
default:
+ /*
+* Private futexes do not hold reference on an inode or
+* mm, therefore the only purpose of calling get_futex_key_refs
+* is because we need the barrier for the lockless waiter check.
+*/
smp_mb(); /* explicit MB (B) */
}
}
/*
* Drop a reference to the resource addressed by a key.
- * The hash bucket spinlock must not be held.
+ * The hash bucket spinlock must not be held. This is
+ * a no-op for private futexes, see comment in the get
+ * counterpart.
*/
static void drop_futex_key_refs(union futex_key *key)
{
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net] bpf: split eBPF out of NET
On Thu, Oct 23, 2014 at 06:41:08PM -0700, Alexei Starovoitov wrote:
> introduce two configs:
> - hidden CONFIG_BPF to select eBPF interpreter that classic socket filters
> depend on
> - visible CONFIG_BPF_SYSCALL (default off) that tracing and sockets can use
>
> that solves several problems:
> - tracing and others that wish to use eBPF don't need to depend on NET.
> They can use BPF_SYSCALL to allow loading from userspace or select BPF
> to use it directly from kernel in NET-less configs.
> - in 3.18 programs cannot be attached to events yet, so don't force it on
> - when the rest of eBPF infra is there in 3.19+, it's still useful to
> switch it off to minimize kernel size
>
> Signed-off-by: Alexei Starovoitov
Thanks for working on this! A few nits below, but otherwise this looks
good to me. Once this gets appropriate reviews from net and bpf folks,
please let me know if you want this to go through the net tree, the tiny
tree, or some other tree.
>
> bloat-o-meter on x64 shows:
> add/remove: 0/60 grow/shrink: 0/2 up/down: 0/-15601 (-15601)
Very nice! Please do include the bloat-o-meter stats in the commit
message.
> tested with many different config combinations. Hopefully didn't miss
> anything.
>
> init/Kconfig| 14 ++
> kernel/Makefile |2 +-
> kernel/bpf/Makefile |6 +++---
> kernel/bpf/core.c |9 +
> net/Kconfig |2 +-
> 5 files changed, 28 insertions(+), 5 deletions(-)
>
> diff --git a/init/Kconfig b/init/Kconfig
> index 3ee28ae..340fd92 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1341,6 +1341,10 @@ config SYSCTL_ARCH_UNALIGN_ALLOW
> config HAVE_PCSPKR_PLATFORM
> bool
>
> +# interpreter that classic socket filters depend on
> +config BPF
> + boolean
s/boolean/bool/
> +
> menuconfig EXPERT
> bool "Configure standard kernel features (expert users)"
> # Unhide debug options, to make the on-by-default options visible
> @@ -1521,6 +1525,16 @@ config EVENTFD
>
> If unsure, say Y.
>
> +# syscall, maps, verifier
> +config BPF_SYSCALL
> + bool "Enable bpf() system call" if EXPERT
> + select ANON_INODES
> + select BPF
> + default n
> + help
> + Enable the bpf() system call that allows to manipulate eBPF
> + programs and maps via file descriptors.
Not sure this one goes under EXPERT, especially since it currently has
"default n".
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c
> @@ -655,3 +655,12 @@ void bpf_prog_free(struct bpf_prog *fp)
> schedule_work(>work);
> }
> EXPORT_SYMBOL_GPL(bpf_prog_free);
> +
> +/* To execute LD_ABS/LD_IND instructions __bpf_prog_run() may call
> + * skb_copy_bits(), so provide a weak definition of it for NET-less config.
> + */
> +int __weak skb_copy_bits(const struct sk_buff *skb, int offset, void *to,
> + int len)
> +{
> + return -EFAULT;
> +}
Please discuss this in the commit message. What are the implications of
ending up with this implementation that always returns -EFAULT?
> diff --git a/net/Kconfig b/net/Kconfig
> index 6272420..99815b5 100644
> --- a/net/Kconfig
> +++ b/net/Kconfig
> @@ -6,7 +6,7 @@ menuconfig NET
> bool "Networking support"
> select NLATTR
> select GENERIC_NET_UTILS
> - select ANON_INODES
> + select BPF
Why does this not need to select ANON_INODES anymore? Did *only* BPF
use that, so it only needs to occur via BPF_SYSCALL? If so, can you
document that in the commit message?
> ---help---
> Unless you really know what you are doing, you should say Y here.
> The reason is that some programs need kernel networking support even
> --
> 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: [GIT PULL] overlay filesystem v25
On Fri, Oct 24, 2014 at 03:20:55AM +0100, Al Viro wrote: > Why the hell do you hold ->i_mutex across the entire opening of underlying > directory? All you need is to serialize one assignment; the side that loses > the race will simply fput() what it opened... > > Oh, well - that goes under "weird pessimisations, easy to fix in followups"... OK, pulled into vfs.git, followups in question added. Also there: fix for a long-standing leak in d_splice_alias() failure exits. Guys, could you check that current vfs.git#for-linus survives your local tests? Seems to survive here; if I don't hear of any problems by tomorrow morning, to Linus it goes... FWIW, for that pull request stats would be Shortlog: Al Viro (5): fix inode leaks on d_splice_alias() failure exits overlayfs: don't hold ->i_mutex over opening the real directory overlayfs: make ovl_cache_entry->name an array instead of pointer overlayfs: embed root into overlay_readdir_data overlayfs: embed middle into overlay_readdir_data Andy Whitcroft (1): overlayfs: add statfs support Erez Zadok (1): overlayfs: implement show_options Miklos Szeredi (11): vfs: add i_op->dentry_open() vfs: export do_splice_direct() to modules vfs: export __inode_permission() to modules vfs: introduce clone_private_mount() vfs: export check_sticky() vfs: add whiteout support vfs: add RENAME_WHITEOUT ext4: support RENAME_WHITEOUT shmem: support RENAME_WHITEOUT overlay filesystem fs: limit filesystem stacking depth Neil Brown (1): overlay: overlay filesystem documentation Diffstat: Documentation/filesystems/Locking |2 + Documentation/filesystems/overlayfs.txt | 198 +++ Documentation/filesystems/vfs.txt |7 + MAINTAINERS |7 + fs/Kconfig |1 + fs/Makefile |1 + fs/btrfs/ioctl.c| 20 +- fs/dcache.c |2 + fs/ecryptfs/main.c |7 + fs/ext4/namei.c | 95 +++- fs/internal.h |7 - fs/namei.c | 41 +- fs/namespace.c | 27 + fs/open.c | 23 +- fs/overlayfs/Kconfig| 10 + fs/overlayfs/Makefile |7 + fs/overlayfs/copy_up.c | 414 ++ fs/overlayfs/dir.c | 921 +++ fs/overlayfs/inode.c| 425 ++ fs/overlayfs/overlayfs.h| 191 +++ fs/overlayfs/readdir.c | 589 fs/overlayfs/super.c| 796 ++ fs/splice.c |1 + include/linux/fs.h | 39 ++ include/linux/mount.h |3 + include/uapi/linux/fs.h |1 + mm/shmem.c | 36 +- 27 files changed, 3813 insertions(+), 58 deletions(-) create mode 100644 Documentation/filesystems/overlayfs.txt create mode 100644 fs/overlayfs/Kconfig create mode 100644 fs/overlayfs/Makefile create mode 100644 fs/overlayfs/copy_up.c create mode 100644 fs/overlayfs/dir.c create mode 100644 fs/overlayfs/inode.c create mode 100644 fs/overlayfs/overlayfs.h create mode 100644 fs/overlayfs/readdir.c create mode 100644 fs/overlayfs/super.c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v13 4/5] ARM: dts: add main Thermal info to rk3288
Dmitry,
在 2014/10/24 10:32, Dmitry Torokhov 写道:
On Fri, Oct 24, 2014 at 10:06:43AM +0800, Caesar Wang wrote:
在 2014/10/24 9:37, Dmitry Torokhov 写道:
On October 23, 2014 6:08:52 PM PDT, Caesar Wang
wrote:
Dmitry,
在 2014/10/24 8:46, Dmitry Torokhov 写道:
Hi Caesar,
On Thu, Oct 23, 2014 at 05:40:06PM +0800, Caesar Wang wrote:
This patch is depend on rk3288-thermal.dtsi,or
it will compile error.
If the temperature over a period of time High,over 120C
the resulting TSHUT gave CRU module,let it reset
the entire chip,or via GPIO give PMIC.
Signed-off-by: Caesar Wang
---
arch/arm/boot/dts/rk3288.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi
b/arch/arm/boot/dts/rk3288.dtsi
index cb18bb4..85fc17a 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include "skeleton.dtsi"
/ {
@@ -66,6 +67,7 @@
216000 90
126000 90
>;
+ #cooling-cells = <2>; /* min followed by max */
clock-latency = <4>;
clocks = < ARMCLK>;
};
@@ -346,6 +348,19 @@
status = "disabled";
};
+ tsadc: tsadc@ff28 {
+ compatible = "rockchip,rk3288-tsadc";
+ reg = <0xff28 0x100>;
+ interrupts = ;
+ clocks = < SCLK_TSADC>, < PCLK_TSADC>;
+ clock-names = "tsadc", "apb_pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <_out>;
+ #thermal-sensor-cells = <1>;
+ hw-shut-temp = <12>;
I do not think this is a good value. You have (in the other DTS file)
passive trip point at 80 and critical (which should result in orderly
shutdown) at 125. But here you define hardware-controlled shutdown at
120C, which is backwards. You should have:
passive <= critical <= hardware
Hmmm
but, the system will shutdown when temperature over critial value,
there is no chance of triggering the TSHUT.
If the temperature over a period of time High,as we know,
the resulting TSHUT gave CRU module,let it hot-reset the entire chip,
or via GPIO give PMIC cold-reset the entire chip.
Having tshut trigger is not the goal, tshut is the measure of last resort. If
we can handle thermal conditions without triggering tshut, we achieved our goal.
Tshut triggering is " oh, crap, nothing we tried works" scenario.
I don't think so.
In general,We should have:
passive <= hardware(reset entire chip) <= critical(shutdown)
The temperature be rising qulckly if have some other conditions,
the "critical" will play a role.
No, I think it should be the other way around: if we are unable to cool
down the laptop under load we need to shut it down and let it cool. If
for some reason we are unable to shut it down in orderly fashion (kernel
is stuck holding a lock or similar) then hardware will reset it.
At least that's how I understand it.
hmmm
OK,agree,this is a option.
I think I should set hw-shut-temp = <125000>;
and critical = <12>;
Thanks.
--
Best regards,
Caesar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ASoC: atmel_ssc_dai: Match the CMR divider only in full duplex.
Hi Peter,
Thanks for your patch.
Btw, do you use "git send-email" command to send the patch?
On 10/22/2014 11:13 PM, Peter Rosin wrote:
From 86be84c4de4e7b21cfda9656a02a902c543210af Mon Sep 17 00:00:00 2001
From: Peter Rosin
Date: Wed, 22 Oct 2014 16:45:29 +0200
Subject: [PATCH v2] ASoC: atmel_ssc_dai: Match the CMR divider only in full
duplex.
The CMR divider register is shared by playback and capture. The SSC driver
therefore tries to enforce rules so that the needed register content do
not conflict during simultaneous playback/capture. However, the
implementation also prevents changing the register content in
half-duplex scenarios, which is needed when using the OSS API.
Thus, only lock the divider if there is a stream in the other direction.
Fixes the below program to not fail with the atmel ssc dai in master mode.
#include
#include
#include
#include
int
main(void)
{
int fd;
int format;
int channels;
int speed;
if ((fd = open("/dev/dsp", O_WRONLY, 0)) == -1) {
perror("open");
return 1;
}
format = AFMT_S16_LE;
if (ioctl(fd, SNDCTL_DSP_SETFMT, ) == -1) {
perror("SNDCTL_DSP_SETFMT");
return 1;
}
channels = 2;
if (ioctl(fd, SNDCTL_DSP_CHANNELS, ) == -1) {
perror("SNDCTL_DSP_CHANNELS");
return 1;
}
speed = 22025;
if (ioctl(fd, SNDCTL_DSP_SPEED, ) == -1) {
perror("SNDCTL_DSP_SPEED");
return 1;
}
return 0;
}
Signed-off-by: Peter Rosin
Acked-by: Bo Shen
---
sound/soc/atmel/atmel_ssc_dai.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
index de433cfd..9ae8475 100644
--- a/sound/soc/atmel/atmel_ssc_dai.c
+++ b/sound/soc/atmel/atmel_ssc_dai.c
@@ -310,7 +310,10 @@ static int atmel_ssc_set_dai_clkdiv(struct snd_soc_dai
*cpu_dai,
* transmit and receive, so if a value has already
* been set, it must match this value.
*/
- if (ssc_p->cmr_div == 0)
+ if (ssc_p->dir_mask !=
+ (SSC_DIR_MASK_PLAYBACK | SSC_DIR_MASK_CAPTURE))
+ ssc_p->cmr_div = div;
+ else if (ssc_p->cmr_div == 0)
ssc_p->cmr_div = div;
else
if (div != ssc_p->cmr_div)
Best Regards,
Bo Shen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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-next] net: phy: Adding SGMII support for Marvell 88ee1145 driver
From: Viet Nga Dao
Additional code to m88e1145_config_init function to allow the driver to
support SGMII mode.
Signed-off-by: Viet Nga Dao
---
drivers/net/phy/marvell.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index bd37e45..b14cb10 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -50,9 +50,13 @@
#define MII_M1011_PHY_SCR 0x10
#define MII_M1011_PHY_SCR_AUTO_CROSS 0x0060
+#define MII_M1145_PHY_EXT_SR 0x1b
#define MII_M1145_PHY_EXT_CR 0x14
#define MII_M1145_RGMII_RX_DELAY 0x0080
#define MII_M1145_RGMII_TX_DELAY 0x0002
+#define MII_M1145_HWCFG_MODE_SGMII_NO_CLK 0x4
+#define MII_M1145_HWCFG_MODE_MASK 0xf
+#define MII_M1145_HWCFG_FIBER_COPPER_AUTO 0x8000
#define MII_M_PHY_LED_CONTROL 0x18
#define MII_M_PHY_LED_DIRECT 0x4100
@@ -620,6 +624,7 @@ static int m88e1149_config_init(struct phy_device *phydev)
static int m88e1145_config_init(struct phy_device *phydev)
{
int err;
+ int temp;
/* Take care of errata E0 & E1 */
err = phy_write(phydev, 0x1d, 0x001b);
@@ -676,6 +681,20 @@ static int m88e1145_config_init(struct phy_device *phydev)
}
}
+ if (phydev->interface == PHY_INTERFACE_MODE_SGMII) {
+ temp = phy_read(phydev, MII_M1145_PHY_EXT_SR);
+ if (temp < 0)
+ return temp;
+
+ temp &= ~(MII_M1145_HWCFG_MODE_MASK);
+ temp |= MII_M1145_HWCFG_MODE_SGMII_NO_CLK;
+ temp |= MII_M1145_HWCFG_FIBER_COPPER_AUTO;
+
+ err = phy_write(phydev, MII_M1145_PHY_EXT_SR, temp);
+ if (err < 0)
+ return err;
+ }
+
err = marvell_of_reg_init(phydev);
if (err < 0)
return err;
--
1.7.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: + mm-compaction-avoid-premature-range-skip-in-isolate_migratepages_range.patch added to -mm tree
On Thu, Oct 23, 2014 at 10:39:45AM +0200, Vlastimil Babka wrote:
> On 10/23/2014 10:15 AM, Joonsoo Kim wrote:
> > On Tue, Oct 14, 2014 at 01:53:44PM -0700, a...@linux-foundation.org wrote:
> >>
> >> The patch titled
> >> Subject: mm/compaction.c: avoid premature range skip in
> >> isolate_migratepages_range
> >> has been added to the -mm tree. Its filename is
> >>
> >> mm-compaction-avoid-premature-range-skip-in-isolate_migratepages_range.patch
> >>
> >> This patch should soon appear at
> >>
> >> http://ozlabs.org/~akpm/mmots/broken-out/mm-compaction-avoid-premature-range-skip-in-isolate_migratepages_range.patch
> >> and later at
> >>
> >> http://ozlabs.org/~akpm/mmotm/broken-out/mm-compaction-avoid-premature-range-skip-in-isolate_migratepages_range.patch
> >>
> >> Before you just go and hit "reply", please:
> >>a) Consider who else should be cc'ed
> >>b) Prefer to cc a suitable mailing list as well
> >>c) Ideally: find the original patch on the mailing list and do a
> >> reply-to-all to that, adding suitable additional cc's
> >>
> >> *** Remember to use Documentation/SubmitChecklist when testing your code
> >> ***
> >>
> >> The -mm tree is included into linux-next and is updated
> >> there every 3-4 working days
> >>
> >> --
> >> From: Joonsoo Kim
> >> Subject: mm/compaction.c: avoid premature range skip in
> >> isolate_migratepages_range
> >>
> >> commit edc2ca612496 ("mm, compaction: move pageblock checks up from
> >> isolate_migratepages_range()") commonizes isolate_migratepages variants
> >> and make them use isolate_migratepages_block().
> >>
> >> isolate_migratepages_block() could stop the execution when enough pages
> >> are isolated, but, there is no code in isolate_migratepages_range() to
> >> handle this case. In the result, even if isolate_migratepages_block()
> >> returns prematurely without checking all pages in the range,
> >>
> >> isolate_migratepages_block() is called repeately on the following
> >> pageblock and some pages in the previous range are skipped to check.
> >> Then, CMA is failed frequently due to this fact.
> >>
> >> To fix this problem, this patch let isolate_migratepages_range() know the
> >> situation that enough pages are isolated and stop the isolation in that
> >> case.
> >>
> >> Note that isolate_migratepages() has no such problem, because, it always
> >> stops the isolation after just one call of isolate_migratepages_block().
> >>
> >> Signed-off-by: Joonsoo Kim
> >> Cc: Vlastimil Babka
> >> Cc: David Rientjes
> >> Cc: Minchan Kim
> >> Cc: Michal Nazarewicz
> >> Cc: Naoya Horiguchi
> >> Cc: Christoph Lameter
> >> Cc: Rik van Riel
> >> Cc: Mel Gorman
> >> Cc: Zhang Yanfei
> >> Signed-off-by: Andrew Morton
>
> Acked-by: Vlastimil Babka
>
> Sorry for the trouble. But I think a more robust and future-proof fix
> would be a check such as: if (pfn < block_end_pfn) break;
> This should catch any reason where isolate_migratepages_block() did not
> finish whole pageblock, and which was not fatal enough to return pfn==0.
> However currently this seems to happen only due to isolating too much,
> so your patch should work.
> So it's up to you if you want to make the check more generic now, or
> later after this bug is fixed for 3.18.
'if (pfn < block_end_pfn) break;' has one problem.
If we have enough isolated pages and reach at block_end_pfn,
we can't stop with above check.
More proper check may be as following.
'if (pfn < block_end_pfn ||
cc->nr_migratepages == COMPACT_CLUSTER_MAX) break;'
But, as you mentioned, there is no case where 'pfn < block_end_pfn'
now, so I'd like to remain the patch as is.
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] i386/audit: stop scribbling on the stack frame
Yes, I will look at this tomorrow. For the record, the calling convention is that eax, edx, ecx are clobbered, and used for the three first arguments in that order. eax, edx are used for the return value(s). The exception is for __asmlinkage functions where all arguments are passed on the stack; something I would like to get rid of but would require changing a lot of assembly code. The same registers are still clobbered, though. On October 23, 2014 1:30:40 PM PDT, Andy Lutomirski wrote: >On Thu, Oct 23, 2014 at 12:30 PM, Eric Paris wrote: >> On Thu, 2014-10-23 at 12:20 -0700, Andy Lutomirski wrote: >>> On Thu, Oct 23, 2014 at 12:15 PM, Eric Paris >wrote: >>> > On Thu, 2014-10-23 at 11:39 -0700, Andy Lutomirski wrote: >>> >> On 10/22/2014 09:04 PM, Eric Paris wrote: >>> >> > git commit b4f0d3755c5e9cc86292d5fd78261903b4f23d4a was very >very dumb. >>> >> > It was writing over %esp/pt_regs semi-randomly on i686 with >the expected >>> >> > "system can't boot" results. As noted in: >>> >> > >>> >> > https://bugs.freedesktop.org/show_bug.cgi?id=85277 >>> >> > >>> >> > This patch stops fscking with pt_regs. Instead it sets up the >registers >>> >> > for the call to __audit_syscall_entry in the most obvious >conceivable >>> >> > way. It then does just a tiny tiny touch of magic. We need to >get what >>> >> > started in PT_EDX into 0(%esp) and PT_ESI into 4(%esp). This >is as easy >>> >> > as a pair of pushes. >>> >> > >>> >> > After the call to __audit_syscall_entry all we need to do is >get that >>> >> > now useless junk off the stack (pair of pops) and reload %eax >with the >>> >> > original syscall so other stuff can keep going about it's >business. >>> >> > >>> >> > Signed-off-by: Eric Paris >>> >> > Cc: Thomas Gleixner >>> >> > Cc: Ingo Molnar >>> >> > Cc: "H. Peter Anvin" >>> >> > Cc: x...@kernel.org >>> >> > Cc: linux-kernel@vger.kernel.org >>> >> > Cc: linux-au...@redhat.com >>> >> > --- >>> >> > arch/x86/kernel/entry_32.S | 15 +++ >>> >> > 1 file changed, 7 insertions(+), 8 deletions(-) >>> >> > >>> >> > diff --git a/arch/x86/kernel/entry_32.S >b/arch/x86/kernel/entry_32.S >>> >> > index f9e3fab..fb01d22 100644 >>> >> > --- a/arch/x86/kernel/entry_32.S >>> >> > +++ b/arch/x86/kernel/entry_32.S >>> >> > @@ -447,15 +447,14 @@ sysenter_exit: >>> >> > sysenter_audit: >>> >> > testl $(_TIF_WORK_SYSCALL_ENTRY & >~_TIF_SYSCALL_AUDIT),TI_flags(%ebp) >>> >> > jnz syscall_trace_entry >>> >> > - addl $4,%esp >>> >> > - CFI_ADJUST_CFA_OFFSET -4 >>> >> > - movl %esi,4(%esp) /* 5th arg: 4th syscall arg >*/ >>> >> > - movl %edx,(%esp)/* 4th arg: 3rd syscall arg >*/ >>> >> > - /* %ecx already in %ecx3rd arg: 2nd syscall arg >*/ >>> >> > - movl %ebx,%edx /* 2nd arg: 1st syscall arg >*/ >>> >> > - /* %eax already in %eax1st arg: syscall number >*/ >>> >> > + /* movl PT_EAX(%esp), %eax already set, syscall >number: 1st arg to audit */ >>> >> > + movl PT_EBX(%esp), %edx /* ebx/a0: 2nd arg to audit >*/ >>> >> > + /* movl PT_ECX(%esp), %ecx already set, a1: 3nd arg to >audit */ >>> >> > + pushl_cfi PT_ESI(%esp) /* a3: 5th arg */ >>> >> > + pushl_cfi PT_EDX+4(%esp)/* a2: 4th arg */ >>> >> > call __audit_syscall_entry >>> >> > - pushl_cfi %ebx >>> >> > + popl_cfi %ecx /* get that remapped edx off the stack */ >>> >> > + popl_cfi %ecx /* get that remapped esi off the stack */ >>> >> > movl PT_EAX(%esp),%eax /* reload syscall number */ >>> >> > jmp sysenter_do_call >>> >> > >>> >> > >>> >> >>> >> This looks reasonably likely to be correct, but this code is >complicated >>> >> and now ever slower. >>> > >>> > I guess I could just use push/pop and do the CFI_ADJUST_CFA_OFFSET >by >>> > hand. But I figured this was reasonable enough... >>> > >>> >>> I'm not complaining about your new assembly in particular. There's >>> just too much assembly in there in general. >>> >>> But I feel like I'm missing something in the new code. Aren't you >>> corrupting ecx with those popl_cfi insns? >> >> After the call __audit_syscall_entry aren't they already polluted? >> Isn't that the reason we need to reload EAX? You can verify this >leaves >> things in a similar state (although slightly differently polluted) >than >> before it got screwed up. Here is diff between before the breakage >and >> what I propose we do now. >> >> (I admit I don't understand how the pushl_cfi %ebx wasn't messing up >> PT_EBX) >> >> /me anxiously awaits x86 guy to tell me how dumb I am >> > >hpa, do you have time to figure this out? I don't know the 32-bit ABI >well enough, nor will I have time to disassemble things or find and >read the spec to figure this out in the next few days. > >--Andy > >> $ git diff a17c8b54dc738c4fda31e8be0302cd131a04c19f -- >arch/x86/kernel/entry_32.S >> diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S >> index
Re: [PATCH 1/2] ima: check xattr value length in ima_inode_setxattr()
On Thu, 23 Oct 2014, Dmitry Kasatkin wrote: > ima_inode_setxattr() can be called with no value. Function does not > check the length so that following command can be used to produce > kernel oops: setfattr -n security.ima FOO. This patch fixes it. I'd like to see more review/acks on this before sending it to Linus. Mimi? -- James Morris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/4] mm: cma: Ensure that reservations never cross the low/high mem boundary
On Thu, Oct 23, 2014 at 05:33:47PM +0300, Laurent Pinchart wrote:
> Commit 95b0e655f914 ("ARM: mm: don't limit default CMA region only to
> low memory") extended CMA memory reservation to allow usage of high
> memory. It relied on commit f7426b983a6a ("mm: cma: adjust address limit
> to avoid hitting low/high memory boundary") to ensure that the reserved
> block never crossed the low/high memory boundary. While the
> implementation correctly lowered the limit, it failed to consider the
> case where the base..limit range crossed the low/high memory boundary
> with enough space on each side to reserve the requested size on either
> low or high memory.
>
> Rework the base and limit adjustment to fix the problem. The function
> now starts by rejecting the reservation altogether for fixed
> reservations that cross the boundary, then adjust the limit if
> reservation from high memory is impossible, and finally first try to
> reserve from high memory first and then falls back to low memory.
>
> Signed-off-by: Laurent Pinchart
> ---
> mm/cma.c | 58 --
> 1 file changed, 44 insertions(+), 14 deletions(-)
>
> diff --git a/mm/cma.c b/mm/cma.c
> index 6b14346..b83597b 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -247,23 +247,38 @@ int __init cma_declare_contiguous(phys_addr_t base,
> return -EINVAL;
>
> /*
> - * adjust limit to avoid crossing low/high memory boundary for
> + * Adjust limit and base to avoid crossing low/high memory boundary for
>* automatically allocated regions
>*/
> - if (((limit == 0 || limit > memblock_end) &&
> - (memblock_end - size < highmem_start &&
> - memblock_end > highmem_start)) ||
> - (!fixed && limit > highmem_start && limit - size < highmem_start)) {
> - limit = highmem_start;
> - }
>
> - if (fixed && base < highmem_start && base+size > highmem_start) {
> + /*
> + * If allocating at a fixed base the request region must not cross the
> + * low/high memory boundary.
> + */
> + if (fixed && base < highmem_start && base + size > highmem_start) {
> ret = -EINVAL;
> pr_err("Region at %08lx defined on low/high memory boundary
> (%08lx)\n",
> (unsigned long)base, (unsigned long)highmem_start);
> goto err;
> }
>
> + /*
> + * If the limit is unspecified or above the memblock end, its effective
> + * value will be the memblock end. Set it explicitly to simplify further
> + * checks.
> + */
> + if (limit == 0 || limit > memblock_end)
> + limit = memblock_end;
> +
> + /*
> + * If the limit is above the highmem start by less than the reserved
> + * size allocation in highmem won't be possible. Lower the limit to the
> + * lowmem end.
> + */
> + if (limit > highmem_start && limit - size < highmem_start)
> + limit = highmem_start;
> +
> +
How about removing this check?
Without this check, memblock_alloc_range would be failed and we can
go fallback correctly. So, this is redundant, IMO.
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 1/4] mm: cma: Don't crash on allocation if CMA area can't be activated
On Fri, Oct 24, 2014 at 10:02:49AM +0800, Weijie Yang wrote: > On Fri, Oct 24, 2014 at 7:42 AM, Laurent Pinchart > wrote: > > Hi Michal, > > > > On Thursday 23 October 2014 18:53:36 Michal Nazarewicz wrote: > >> On Thu, Oct 23 2014, Laurent Pinchart wrote: > >> > If activation of the CMA area fails its mutex won't be initialized, > >> > leading to an oops at allocation time when trying to lock the mutex. Fix > >> > this by failing allocation if the area hasn't been successfully actived, > >> > and detect that condition by moving the CMA bitmap allocation after page > >> > block reservation completion. > >> > > >> > Signed-off-by: Laurent Pinchart > >> > > >> > >> Cc: # v3.17 > >> Acked-by: Michal Nazarewicz > > This patch is good, but how about add a active field in cma struct? > use cma->active to check whether cma is actived successfully. > I think it will make code more clear and readable. > Just my little opinion. > Or just setting cma->count to 0 would work fine. 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 3/3] ARM: shmobile: armadillo800eva dts: Enable TMU0
On Wed, Oct 22, 2014 at 05:17:06PM +0200, Geert Uytterhoeven wrote: > On Wed, Oct 22, 2014 at 4:58 PM, Laurent Pinchart > wrote: > > On Wednesday 22 October 2014 11:38:29 Geert Uytterhoeven wrote: > >> ch0 will be used for clock events and for periodic clock events, > >> ch1 will be used as clock source. > >> > >> Signed-off-by: Geert Uytterhoeven > > > > Simon has posted the same change as "[PATCH v2 20/30] ARM: shmobile: > > armadillo800eva-reference: Initialise TMU device using DT". You might want > > to > > credit him. > > Bummer, didn't look hard enough... > > Simon: what's the reason these hadn't been applied yet? > Likewise for r8a7778. Good question. It looks like a number of patches from that series slipped through the cracks. I have queued up your r8a7740 patches (patches 2 and 3 of this series) and my r8a7778 patches. I have also queued up my r8a73a4 CMT1 patches from the same series that Laurent referred to above. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PATCHSET 0/5] perf tools: Speed up dwarf callchain post-unwinding for libunwind (v4)
On Fri, Oct 24, 2014 at 10:56 AM, Arnaldo Carvalho de Melo wrote: > Em Fri, Oct 24, 2014 at 09:44:17AM +0900, Namhyung Kim escreveu: >> On Thu, 23 Oct 2014 20:35:42 -0300, Arnaldo Carvalho de Melo wrote: >> > I'll push later and will drop you a note, so that you can, please, check >> > if the end result is sane. >> >> Thank you! > > It should be on my perf/core branch by now. Looks ok to me. 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 1/3] clocksource: sh_tmu: Document R-Mobile r8a7740 binding
On Wed, Oct 22, 2014 at 05:59:25PM +0300, Laurent Pinchart wrote: > Hi Geert, > > Thank you for the patch. > > On Wednesday 22 October 2014 11:38:27 Geert Uytterhoeven wrote: > > Compared to the r8a7779, the r8a7740 lacks the input capture register, > > which is not used by the driver (the current driver already handles the > > r8a7740 in the non-DT case). > > > > Signed-off-by: Geert Uytterhoeven > > Acked-by: Laurent Pinchart Acked-by: Simon Horman > > > --- > > Documentation/devicetree/bindings/timer/renesas,tmu.txt | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/devicetree/bindings/timer/renesas,tmu.txt > > b/Documentation/devicetree/bindings/timer/renesas,tmu.txt index > > 7db89fb2544411b5..4ae7910af09ffcb4 100644 > > --- a/Documentation/devicetree/bindings/timer/renesas,tmu.txt > > +++ b/Documentation/devicetree/bindings/timer/renesas,tmu.txt > > @@ -1,4 +1,4 @@ > > -* Renesas R-Car Timer Unit (TMU) > > +* Renesas R-Mobile/R-Car Timer Unit (TMU) > > > > The TMU is a 32-bit timer/counter with configurable clock inputs and > > programmable compare match. > > @@ -9,6 +9,7 @@ are independent. The TMU hardware supports up to three > > channels. Required Properties: > > > >- compatible: must contain one or more of the following: > > +- "renesas,tmu-r8a7740" for the r8a7740 TMU > > - "renesas,tmu-r8a7779" for the r8a7779 TMU > > - "renesas,tmu" for any TMU. > >This is a fallback for the above renesas,tmu-* entries > > -- > Regards, > > Laurent Pinchart > > -- > To unsubscribe from this list: send the line "unsubscribe linux-sh" 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: [RFC PATCH 3/3] i915: Expose PMU for Observation Architecture
On Thu, Oct 23, 2014 at 8:47 AM, Chris Wilson wrote:
> On Wed, Oct 22, 2014 at 04:28:51PM +0100, Robert Bragg wrote:
>> + /* XXX: Not sure that this is really acceptable...
>> + *
>> + * i915_gem_context.c currently owns pinning/unpinning legacy
>> + * context buffers and although that code has a
>> + * get_context_alignment() func to handle a different
>> + * constraint for gen6 we are assuming it's fixed for gen7
>> + * here. Another option besides pinning here would be to
>> + * instead hook into context switching and update the
>> + * OACONTROL configuration on the fly.
>> + */
>> + if (dev_priv->oa_pmu.specific_ctx) {
>> + struct intel_context *ctx = dev_priv->oa_pmu.specific_ctx;
>> + int ret;
>> +
>> + ret = i915_gem_obj_ggtt_pin(ctx->legacy_hw_ctx.rcs_state,
>> + 4096, 0);
>
> Right if you pin it here with a different alignment, when we try to pin
> it with the required hw ctx alignment it will fail. Easiest way is to
> record the ctx->legacy_hw_ctx.alignment and reuse that here.
Ok I can look into that a bit more. I'm not currently sure I can assume the
ctx will have been pinned before, to be able to record the alignment.
Skimming i915_gem_context.c, it looks like we only pin the default context
on creation and a user could open a perf even before we first switch to that
context.
I wonder if it would be ok to expose an i915_get_context_alignment() api to
deal with this?
>
>> + if (ret) {
>> + DRM_DEBUG_DRIVER("Couldn't pin %d\n", ret);
>> + ret = -EBUSY;
>
> As an exercise, think of all the possible error values from pin() and
> tell me why overriding that here is a bad, bad idea.
Hmm, I'm not quite sure why I decided to squash the error code there, it
looks pretty arbitrary. My take on your comment a.t.m is essentially that
some of the pin() errors don't really represent a busy state where it would
make sense for userspace to try again later; such as -ENODEV. Sorry if you
saw a very specific case that offended you :-) I have removed the override
locally.
Thanks for taking a look.
- Robert
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v13 4/5] ARM: dts: add main Thermal info to rk3288
On Fri, Oct 24, 2014 at 10:06:43AM +0800, Caesar Wang wrote:
>
> 在 2014/10/24 9:37, Dmitry Torokhov 写道:
> >On October 23, 2014 6:08:52 PM PDT, Caesar Wang
> >wrote:
> >>Dmitry,
> >>
> >>在 2014/10/24 8:46, Dmitry Torokhov 写道:
> >>>Hi Caesar,
> >>>
> >>>On Thu, Oct 23, 2014 at 05:40:06PM +0800, Caesar Wang wrote:
> This patch is depend on rk3288-thermal.dtsi,or
> it will compile error.
>
> If the temperature over a period of time High,over 120C
> the resulting TSHUT gave CRU module,let it reset
> the entire chip,or via GPIO give PMIC.
>
> Signed-off-by: Caesar Wang
> ---
> arch/arm/boot/dts/rk3288.dtsi | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm/boot/dts/rk3288.dtsi
> >>b/arch/arm/boot/dts/rk3288.dtsi
> index cb18bb4..85fc17a 100644
> --- a/arch/arm/boot/dts/rk3288.dtsi
> +++ b/arch/arm/boot/dts/rk3288.dtsi
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
> #include "skeleton.dtsi"
> / {
> @@ -66,6 +67,7 @@
> 216000 90
> 126000 90
> >;
> + #cooling-cells = <2>; /* min followed by max */
> clock-latency = <4>;
> clocks = < ARMCLK>;
> };
> @@ -346,6 +348,19 @@
> status = "disabled";
> };
> + tsadc: tsadc@ff28 {
> + compatible = "rockchip,rk3288-tsadc";
> + reg = <0xff28 0x100>;
> + interrupts = ;
> + clocks = < SCLK_TSADC>, < PCLK_TSADC>;
> + clock-names = "tsadc", "apb_pclk";
> + pinctrl-names = "default";
> + pinctrl-0 = <_out>;
> + #thermal-sensor-cells = <1>;
> + hw-shut-temp = <12>;
> >>>I do not think this is a good value. You have (in the other DTS file)
> >>>passive trip point at 80 and critical (which should result in orderly
> >>>shutdown) at 125. But here you define hardware-controlled shutdown at
> >>>120C, which is backwards. You should have:
> >>>
> >>>passive <= critical <= hardware
> >>Hmmm
> >>but, the system will shutdown when temperature over critial value,
> >>there is no chance of triggering the TSHUT.
> >>
> >>If the temperature over a period of time High,as we know,
> >>the resulting TSHUT gave CRU module,let it hot-reset the entire chip,
> >>or via GPIO give PMIC cold-reset the entire chip.
> >Having tshut trigger is not the goal, tshut is the measure of last resort.
> >If we can handle thermal conditions without triggering tshut, we achieved
> >our goal.
> >
> >Tshut triggering is " oh, crap, nothing we tried works" scenario.
>
> I don't think so.
>
> In general,We should have:
> passive <= hardware(reset entire chip) <= critical(shutdown)
>
> The temperature be rising qulckly if have some other conditions,
> the "critical" will play a role.
No, I think it should be the other way around: if we are unable to cool
down the laptop under load we need to shut it down and let it cool. If
for some reason we are unable to shut it down in orderly fashion (kernel
is stuck holding a lock or similar) then hardware will reset it.
At least that's how I understand it.
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/4] fix freepage count problems in memory isolation
Hi Joonsoo, I know you spend much effort for investigate/fix this subtle problem. So, you should be hero. Thanks for really nice work! On Thu, Oct 23, 2014 at 05:10:17PM +0900, Joonsoo Kim wrote: > Changes from v3 to v4 > * Patch 1: Add code comment on nr_isolate_pageblock on struct zone (Naoya) > Add one more check in free_one_page() that checks whether > migratetype is MIGRATE_ISOLATE or not. > * Patch 4: Use min() to prevent overflow of buddy merge order (Naoya) > * Remove RFC tag > * Add stable tag on all patches > > Changes from v1, v2 to v3 > * A lot of comments that lead this patchset to right direction > (Vlastimil and Minchan) > > This is version 4 patchset which is improved and minimized version of > version 1 to fix freepage accounting problem during memory isolation. > I tried different approach in version 2, but, it looks really complicated > so I change my mind to improve version 1. You can see version 1, 2 in > following links [1] [2], respectively. > > IMO, this v3 is better than v2, because this is simpler than v2 so > better for maintainance and this doesn't change pageblock isolation > logic so it is much easier to backport. > > This problems are found by testing my patchset [3]. There are some race > conditions on pageblock isolation and these race cause incorrect > freepage count. > > Before describing bugs itself, I first explain definition of freepage. > > 1. pages on buddy list are counted as freepage. > 2. pages on isolate migratetype buddy list are *not* counted as freepage. > 3. pages on cma buddy list are counted as CMA freepage, too. > > Now, I describe problems and related patch. > > Patch 1: There is race conditions on getting pageblock migratetype that > it results in misplacement of freepages on buddy list, incorrect > freepage count and un-availability of freepage. > > Patch 2: Freepages on pcp list could have stale cached information to > determine migratetype of buddy list to go. This causes misplacement > of freepages on buddy list and incorrect freepage count. > > Patch 4: Merging between freepages on different migratetype of > pageblocks will cause freepages accouting problem. This patch fixes it. > > Without patchset [3], above problem doesn't happens on my CMA allocation > test, because CMA reserved pages aren't used at all. So there is no > chance for above race. > > With patchset [3], I did simple CMA allocation test and get below result. > > - Virtual machine, 4 cpus, 1024 MB memory, 256 MB CMA reservation > - run kernel build (make -j16) on background > - 30 times CMA allocation(8MB * 30 = 240MB) attempts in 5 sec interval > - Result: more than 5000 freepage count are missed > > With patchset [3] and this patchset, I found that no freepage count are > missed so that I conclude that problems are solved. > > On my simple memory offlining test, these problems also occur on that > environment. > > This patchset is based on v3.18-rc1. > Please see individual patches for more information. > > Thanks. > > [1]: https://lkml.org/lkml/2014/7/4/79 > [2]: lkml.org/lkml/2014/8/6/52 > [3]: Aggressively allocate the pages on cma reserved memory > https://lkml.org/lkml/2014/5/30/291 > > Joonsoo Kim (4): > mm/page_alloc: fix incorrect isolation behavior by rechecking > migratetype > mm/page_alloc: add freepage on isolate pageblock to correct buddy > list > mm/page_alloc: move migratetype recheck logic to __free_one_page() So, [1-3], Acked-by: Minchan Kim > mm/page_alloc: restrict max order of merging on isolated pageblock As you noted in description, this patch has a side effect which doesn't merge buddies. Most of all, I agree your assumptions but it's not true always. Who knows there is a driver which want a higher page above pageblock? Who knows there is no allocation/free of the isolated range right before highest allocation request? Even, your patch introduces new exception rule for page allocator. "Hey, allocator, from now on, you could have unmerged buddies in your list so please advertise it to your customer" So, all of users of the allocator should consider that exception so it might hit us sometime. I want to fix that in isolation undo time. Thanks, again! > > include/linux/mmzone.h |9 + > include/linux/page-isolation.h |8 > mm/page_alloc.c| 29 - > mm/page_isolation.c|2 ++ > 4 files changed, 39 insertions(+), 9 deletions(-) > > -- > 1.7.9.5 > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] overlay filesystem v25
On Fri, Oct 24, 2014 at 01:25:39AM +0200, Miklos Szeredi wrote: > Linus, > > Please pull > > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git overlayfs.v25 > > Plenty of bugs fixed relative to the previous version, thanks to Al Viro's > review and is now officially be BugFree(TM). Also passes the > unionmount-testsuite by David Howells. *blink* Why the hell do you hold ->i_mutex across the entire opening of underlying directory? All you need is to serialize one assignment; the side that loses the race will simply fput() what it opened... Oh, well - that goes under "weird pessimisations, easy to fix in followups"... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v13 3/5] ARM: dts: add RK3288 Thermal data
Dmitry,
在 2014/10/24 8:48, Dmitry Torokhov 写道:
Hi Caesar,
On Thu, Oct 23, 2014 at 05:40:05PM +0800, Caesar Wang wrote:
This patch changes a dtsi file to contain the thermal data
on RK3288 and later SoCs. This data will
enable a thermal shutdown over 125C.
Signed-off-by: Caesar Wang
---
arch/arm/boot/dts/rk3288-thermal.dtsi | 65 +++
1 file changed, 65 insertions(+)
create mode 100644 arch/arm/boot/dts/rk3288-thermal.dtsi
diff --git a/arch/arm/boot/dts/rk3288-thermal.dtsi
b/arch/arm/boot/dts/rk3288-thermal.dtsi
new file mode 100644
index 000..c361262
--- /dev/null
+++ b/arch/arm/boot/dts/rk3288-thermal.dtsi
@@ -0,0 +1,65 @@
+/*
+ * Device Tree Source for RK3288 SoC thermal
+ *
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include
+
+reserve_thermal: reserve_thermal {
+ polling-delay-passive = <500>; /* milliseconds */
+ polling-delay = <1000>; /* milliseconds */
+
+ /* sensor ID */
+ thermal-sensors = <0>;
+
+};
+
+cpu_thermal: cpu_thermal {
+ polling-delay-passive = <500>; /* milliseconds */
+ polling-delay = <1000>; /* milliseconds */
Given that the hardware supports alarm interrupts I think we should be
able to lower polling frequency. I'd say 5 seconds for polling-delay and
1 second for when we trip over passive point?
As you say:
+cpu_thermal: cpu_thermal {
+ polling-delay-passive = <1000>; /* milliseconds */
+ polling-delay = <5000>; /* milliseconds */
I think it's ok for me if the driver follow your change.
Thanks.
--
Best regards,
Caesar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] clocksource: sh_mtu2: Correct SoC family name
On Wed, Oct 22, 2014 at 06:00:19PM +0300, Laurent Pinchart wrote: > Hi Geert, > > Thank you for the patch. > > On Wednesday 22 October 2014 11:26:18 Geert Uytterhoeven wrote: > > r7s72100 is a member of the RZ family, not of the R-Car family > > > > Signed-off-by: Geert Uytterhoeven > > Acked-by: Laurent Pinchart My understanding is that mtu2 is an IP block that has been around inside Renesas for quite some time and has a history of use on the SH architecture as well as its more recent use on the r7s72100. So perhaps "Renesas Multi-Function Timer Pulse Unit 2 (MTU2)" would be (slightly) better. > > --- > > Documentation/devicetree/bindings/timer/renesas,mtu2.txt | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/Documentation/devicetree/bindings/timer/renesas,mtu2.txt > > b/Documentation/devicetree/bindings/timer/renesas,mtu2.txt index > > d9a8d5af1a21270f..55484a77a6ae54d0 100644 > > --- a/Documentation/devicetree/bindings/timer/renesas,mtu2.txt > > +++ b/Documentation/devicetree/bindings/timer/renesas,mtu2.txt > > @@ -1,4 +1,4 @@ > > -* Renesas R-Car Multi-Function Timer Pulse Unit 2 (MTU2) > > +* Renesas RZ Multi-Function Timer Pulse Unit 2 (MTU2) > > > > The MTU2 is a multi-purpose, multi-channel timer/counter with configurable > > clock inputs and programmable compare match. > > -- > Regards, > > Laurent Pinchart > > -- > To unsubscribe from this list: send the line "unsubscribe linux-sh" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 3/3] staging: skein: Inlines rotl_64
Inlines the macro definition rotl_64 to avoid bugs.
Signed-off-by: Eric Rost
---
drivers/staging/skein/skein_base.h | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/skein/skein_base.h
b/drivers/staging/skein/skein_base.h
index 9f10af9..769bcb4 100644
--- a/drivers/staging/skein/skein_base.h
+++ b/drivers/staging/skein/skein_base.h
@@ -33,10 +33,6 @@
#define SKEIN512_DIGEST_BIT_SIZE 512
#define SKEIN1024_DIGEST_BIT_SIZE 1024
-#ifndef rotl_64
-#define rotl_64(x, N)(((x) << (N)) | ((x) >> (64-(N
-#endif
-
/* below two prototype assume we are handed aligned data */
#define skein_put64_lsb_first(dst08, src64, b_cnt) memcpy(dst08, src64, b_cnt)
#define skein_get64_lsb_first(dst64, src08, w_cnt) \
@@ -92,6 +88,11 @@ struct skein_1024_ctx { /* 1024-bit Skein hash context
structure */
u8 b[SKEIN_1024_BLOCK_BYTES]; /* partial block buf (8-byte aligned) */
};
+static inline int rotl_64(int x, int N)
+{
+ return (x << N) | (x >> (64 - N));
+}
+
/* Skein APIs for (incremental) "straight hashing" */
int skein_256_init(struct skein_256_ctx *ctx, size_t hash_bit_len);
int skein_512_init(struct skein_512_ctx *ctx, size_t hash_bit_len);
--
2.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] virtio_blk: fix race at module removal
On Fri, Oct 24, 2014 at 12:12 AM, Michael S. Tsirkin wrote:
> If a device appears while module is being removed,
> driver will get a callback after we've given up
> on the major number.
>
> In theory this means this major number can get reused
> by something else, resulting in a conflict.
Yes, there is a tiny race window.
>
> To fix, cleanup in reverse order of initialization.
Reviewed-by: Ming Lei
> Signed-off-by: Michael S. Tsirkin
> ---
> drivers/block/virtio_blk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> index 56aadbc..adfba9f 100644
> --- a/drivers/block/virtio_blk.c
> +++ b/drivers/block/virtio_blk.c
> @@ -883,8 +883,8 @@ out_destroy_workqueue:
>
> static void __exit fini(void)
> {
> - unregister_blkdev(major, "virtblk");
> unregister_virtio_driver(_blk);
> + unregister_blkdev(major, "virtblk");
> destroy_workqueue(virtblk_wq);
> }
> module_init(init);
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/
[PATCH v4 2/3] staging: skein: Adds Loadable Module Support
Adds loadable module support for the Skein Hashing Algorithm.
Signed-off-by: Eric Rost
---
drivers/staging/skein/Kconfig | 2 +-
drivers/staging/skein/skein_generic.c | 19 ++-
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/skein/Kconfig b/drivers/staging/skein/Kconfig
index de8bdd7..012a823 100644
--- a/drivers/staging/skein/Kconfig
+++ b/drivers/staging/skein/Kconfig
@@ -1,5 +1,5 @@
config CRYPTO_SKEIN
- bool "Skein digest algorithm"
+ tristate "Skein digest algorithm"
depends on (X86 || UML_X86) && 64BIT && CRYPTO
select CRYPTO_HASH
select CRYPTO_ALGAPI
diff --git a/drivers/staging/skein/skein_generic.c
b/drivers/staging/skein/skein_generic.c
index 815f9a4..3c9c6d0 100644
--- a/drivers/staging/skein/skein_generic.c
+++ b/drivers/staging/skein/skein_generic.c
@@ -16,6 +16,7 @@
*/
#include
#include
+#include
#include
#include "skein_base.h"
@@ -142,6 +143,7 @@ static struct shash_alg alg256 = {
.cra_driver_name= "skein",
.cra_flags = CRYPTO_ALG_TYPE_SHASH,
.cra_blocksize = SKEIN_256_BLOCK_BYTES,
+ .cra_module = THIS_MODULE,
}
};
@@ -159,6 +161,7 @@ static struct shash_alg alg512 = {
.cra_driver_name= "skein",
.cra_flags = CRYPTO_ALG_TYPE_SHASH,
.cra_blocksize = SKEIN_512_BLOCK_BYTES,
+ .cra_module = THIS_MODULE,
}
};
@@ -176,6 +179,7 @@ static struct shash_alg alg1024 = {
.cra_driver_name= "skein",
.cra_flags = CRYPTO_ALG_TYPE_SHASH,
.cra_blocksize = SKEIN_1024_BLOCK_BYTES,
+ .cra_module = THIS_MODULE,
}
};
@@ -191,4 +195,17 @@ static int __init skein_generic_init(void)
return 0;
}
-device_initcall(skein_generic_init);
+static void __exit skein_generic_fini(void)
+{
+ crypto_unregister_shash();
+ crypto_unregister_shash();
+ crypto_unregister_shash();
+}
+
+module_init(skein_generic_init);
+module_exit(skein_generic_fini);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Skein Hash Algorithm");
+
+MODULE_ALIAS("skein");
--
2.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 1/5] mfd: tps65910: Convert ti,system-power-controller DT property to poweroff-source
On Thu, Oct 23, 2014 at 6:39 PM, PERIER Romain wrote: > Hi Peter, > > 2014-10-23 10:12 GMT+02:00 Peter De Schrijver : >> This breaks DT ABI stability right? An existing device tree using >> ti,system-power-controller won't work anymore after this patch right? I >> don't think that's acceptable. >> > > This is why I converted all dts which use "ti,system-power-controller" > and tps65910/tps65911 to the new property (everything is in the > patches serie). However, with an existing dtb it will no longer work, > yes. > What do you suggest ? keep these two properties in the driver ? :/ > > I mean, this is a standardization, so all the corresponding dts must > be updated and rebuilt... Like when you change something in a > dt-binding, you should update and rebuilt the dts... I Don't compute. DT ABI stability rule: any DTB that worked with kernel x must also work with kernel x+1. It seems like this patch would break that rule. It's ok to manage new properties and to deprecate the use of older ones if it makes sense (and in this case it seems like it does). But the old property must still be handled for compatibility reasons. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/3] staging: skein: Adds CryptoAPI Support
Adds CryptoAPI support for skein256, skein512, and skein1024
algorithms. Also collapses threefish algorithm into skein.o and removes
Kconfig option for Threefish.
Signed-off-by: Eric Rost
---
drivers/staging/skein/Kconfig | 22 +-
drivers/staging/skein/Makefile| 13 +-
drivers/staging/skein/skein.c | 883 -
drivers/staging/skein/skein.h | 346 -
drivers/staging/skein/skein_api.h | 2 +-
drivers/staging/skein/skein_base.c| 884 ++
drivers/staging/skein/skein_base.h| 351 ++
drivers/staging/skein/skein_block.c | 2 +-
drivers/staging/skein/skein_block.h | 2 +-
drivers/staging/skein/skein_generic.c | 194
drivers/staging/skein/skein_iv.h | 2 +-
drivers/staging/skein/threefish_api.h | 2 +-
12 files changed, 1444 insertions(+), 1259 deletions(-)
delete mode 100644 drivers/staging/skein/skein.c
delete mode 100644 drivers/staging/skein/skein.h
create mode 100644 drivers/staging/skein/skein_base.c
create mode 100644 drivers/staging/skein/skein_base.h
create mode 100644 drivers/staging/skein/skein_generic.c
diff --git a/drivers/staging/skein/Kconfig b/drivers/staging/skein/Kconfig
index b9172bf..de8bdd7 100644
--- a/drivers/staging/skein/Kconfig
+++ b/drivers/staging/skein/Kconfig
@@ -1,8 +1,8 @@
config CRYPTO_SKEIN
bool "Skein digest algorithm"
depends on (X86 || UML_X86) && 64BIT && CRYPTO
- select CRYPTO_THREEFISH
select CRYPTO_HASH
+ select CRYPTO_ALGAPI
help
Skein secure hash algorithm is one of 5 finalists from the NIST SHA3
competition.
@@ -12,21 +12,5 @@ config CRYPTO_SKEIN
http://www.skein-hash.info/sites/default/files/skein1.3.pdf
- for more information. This module depends on the threefish block
- cipher module.
-
-config CRYPTO_THREEFISH
- bool "Threefish tweakable block cipher"
- depends on (X86 || UML_X86) && 64BIT && CRYPTO
- select CRYPTO_ALGAPI
- help
- Threefish cipher algorithm is the tweakable block cipher underneath
- the Skein family of secure hash algorithms. Skein is one of 5
- finalists from the NIST SHA3 competition.
-
- Skein is optimized for modern, 64bit processors and is highly
- customizable. See:
-
- http://www.skein-hash.info/sites/default/files/skein1.3.pdf
-
- for more information.
+ for more information. This module also contains the threefish block
+ cipher algorithm.
diff --git a/drivers/staging/skein/Makefile b/drivers/staging/skein/Makefile
index a14aadd..66c8799 100644
--- a/drivers/staging/skein/Makefile
+++ b/drivers/staging/skein/Makefile
@@ -1,9 +1,10 @@
#
# Makefile for the skein secure hash algorithm
#
-obj-$(CONFIG_CRYPTO_SKEIN) += skein.o \
- skein_api.o \
- skein_block.o
-
-obj-$(CONFIG_CRYPTO_THREEFISH) += threefish_block.o \
- threefish_api.o
+obj-$(CONFIG_CRYPTO_SKEIN) += skein.o
+skein-y := skein_base.o \
+ skein_api.o \
+ skein_block.o \
+ threefish_block.o \
+ threefish_api.o \
+ skein_generic.o
diff --git a/drivers/staging/skein/skein.c b/drivers/staging/skein/skein.c
deleted file mode 100644
index 8cc8358..000
--- a/drivers/staging/skein/skein.c
+++ /dev/null
@@ -1,883 +0,0 @@
-/***
-**
-** Implementation of the Skein hash function.
-**
-** Source code author: Doug Whiting, 2008.
-**
-** This algorithm and source code is released to the public domain.
-**
-/
-
-#define SKEIN_PORT_CODE /* instantiate any code in skein_port.h */
-
-#include/* get the memcpy/memset functions */
-#include "skein.h" /* get the Skein API definitions */
-#include "skein_iv.h"/* get precomputed IVs */
-#include "skein_block.h"
-
-/*/
-/* 256-bit Skein */
-/*/
-
-/**/
-/* init the context for a straight hashing operation */
-int skein_256_init(struct skein_256_ctx *ctx, size_t hash_bit_len)
-{
- union {
- u8 b[SKEIN_256_STATE_BYTES];
- u64 w[SKEIN_256_STATE_WORDS];
- } cfg; /* config block */
-
- skein_assert_ret(hash_bit_len > 0, SKEIN_BAD_HASHLEN);
- ctx->h.hash_bit_len = hash_bit_len; /* output hash bit count */
-
- switch (hash_bit_len) { /* use pre-computed values, where available */
- case 256:
- memcpy(ctx->x, SKEIN_256_IV_256, sizeof(ctx->x));
- break;
- case
[PATCH v4 0/3] staging: skein: Adds CryptoAPI and Module Support
Adds CryptoAPI and Loadable Module support to the Skein Hash Algorithm. Also inlines the rotl_64 macro. Eric Rost (3): staging: skein: Adds CryptoAPI Support staging: skein: Adds Loadable Module Support staging: skein: Inlines rotl_64 drivers/staging/skein/Kconfig | 24 +- drivers/staging/skein/Makefile| 13 +- drivers/staging/skein/skein.c | 883 - drivers/staging/skein/skein.h | 346 - drivers/staging/skein/skein_api.h | 2 +- drivers/staging/skein/skein_base.c| 884 ++ drivers/staging/skein/skein_base.h| 352 ++ drivers/staging/skein/skein_block.c | 2 +- drivers/staging/skein/skein_block.h | 2 +- drivers/staging/skein/skein_generic.c | 211 drivers/staging/skein/skein_iv.h | 2 +- drivers/staging/skein/threefish_api.h | 2 +- 12 files changed, 1463 insertions(+), 1260 deletions(-) delete mode 100644 drivers/staging/skein/skein.c delete mode 100644 drivers/staging/skein/skein.h create mode 100644 drivers/staging/skein/skein_base.c create mode 100644 drivers/staging/skein/skein_base.h create mode 100644 drivers/staging/skein/skein_generic.c -- 2.1.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v13 4/5] ARM: dts: add main Thermal info to rk3288
在 2014/10/24 9:37, Dmitry Torokhov 写道:
On October 23, 2014 6:08:52 PM PDT, Caesar Wang
wrote:
Dmitry,
在 2014/10/24 8:46, Dmitry Torokhov 写道:
Hi Caesar,
On Thu, Oct 23, 2014 at 05:40:06PM +0800, Caesar Wang wrote:
This patch is depend on rk3288-thermal.dtsi,or
it will compile error.
If the temperature over a period of time High,over 120C
the resulting TSHUT gave CRU module,let it reset
the entire chip,or via GPIO give PMIC.
Signed-off-by: Caesar Wang
---
arch/arm/boot/dts/rk3288.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi
b/arch/arm/boot/dts/rk3288.dtsi
index cb18bb4..85fc17a 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include "skeleton.dtsi"
/ {
@@ -66,6 +67,7 @@
216000 90
126000 90
>;
+ #cooling-cells = <2>; /* min followed by max */
clock-latency = <4>;
clocks = < ARMCLK>;
};
@@ -346,6 +348,19 @@
status = "disabled";
};
+ tsadc: tsadc@ff28 {
+ compatible = "rockchip,rk3288-tsadc";
+ reg = <0xff28 0x100>;
+ interrupts = ;
+ clocks = < SCLK_TSADC>, < PCLK_TSADC>;
+ clock-names = "tsadc", "apb_pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <_out>;
+ #thermal-sensor-cells = <1>;
+ hw-shut-temp = <12>;
I do not think this is a good value. You have (in the other DTS file)
passive trip point at 80 and critical (which should result in orderly
shutdown) at 125. But here you define hardware-controlled shutdown at
120C, which is backwards. You should have:
passive <= critical <= hardware
Hmmm
but, the system will shutdown when temperature over critial value,
there is no chance of triggering the TSHUT.
If the temperature over a period of time High,as we know,
the resulting TSHUT gave CRU module,let it hot-reset the entire chip,
or via GPIO give PMIC cold-reset the entire chip.
Having tshut trigger is not the goal, tshut is the measure of last resort. If
we can handle thermal conditions without triggering tshut, we achieved our goal.
Tshut triggering is " oh, crap, nothing we tried works" scenario.
I don't think so.
In general,We should have:
passive <= hardware(reset entire chip) <= critical(shutdown)
The temperature be rising qulckly if have some other conditions,
the "critical" will play a role.
Agreed?
Thanks.
--
Best regards,
Caesar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] mm: cma: Don't crash on allocation if CMA area can't be activated
On Fri, Oct 24, 2014 at 7:42 AM, Laurent Pinchart
wrote:
> Hi Michal,
>
> On Thursday 23 October 2014 18:53:36 Michal Nazarewicz wrote:
>> On Thu, Oct 23 2014, Laurent Pinchart wrote:
>> > If activation of the CMA area fails its mutex won't be initialized,
>> > leading to an oops at allocation time when trying to lock the mutex. Fix
>> > this by failing allocation if the area hasn't been successfully actived,
>> > and detect that condition by moving the CMA bitmap allocation after page
>> > block reservation completion.
>> >
>> > Signed-off-by: Laurent Pinchart
>> >
>>
>> Cc: # v3.17
>> Acked-by: Michal Nazarewicz
This patch is good, but how about add a active field in cma struct?
use cma->active to check whether cma is actived successfully.
I think it will make code more clear and readable.
Just my little opinion.
>> As a matter of fact, this is present in kernels earlier than 3.17 but in
>> the 3.17 the code has been moved from drivers/base/dma-contiguous.c to
>> mm/cma.c so this might require separate stable patch. I can track this
>> and prepare a patch if you want.
>
> That could be done, but I'm not sure if it's really worth it. The bug only
> occurs when the CMA zone activation fails. I've ran into that case due to a
> bug introduced in v3.18-rc1, but this shouldn't be the case for older kernel
> versions.
>
> If you think the fix should be backported to stable kernels older than v3.17
> please feel free to cook up a patch.
>
>> > ---
>> >
>> > mm/cma.c | 17 ++---
>> > 1 file changed, 6 insertions(+), 11 deletions(-)
>> >
>> > diff --git a/mm/cma.c b/mm/cma.c
>> > index 963bc4a..16c6650 100644
>> > --- a/mm/cma.c
>> > +++ b/mm/cma.c
>> > @@ -93,11 +93,6 @@ static int __init cma_activate_area(struct cma *cma)
>> > unsigned i = cma->count >> pageblock_order;
>> > struct zone *zone;
>> >
>> > - cma->bitmap = kzalloc(bitmap_size, GFP_KERNEL);
>> > -
>> > - if (!cma->bitmap)
>> > - return -ENOMEM;
>> > -
>> > WARN_ON_ONCE(!pfn_valid(pfn));
>> > zone = page_zone(pfn_to_page(pfn));
>> >
>> > @@ -114,17 +109,17 @@ static int __init cma_activate_area(struct cma *cma)
>> > * to be in the same zone.
>> > */
>> > if (page_zone(pfn_to_page(pfn)) != zone)
>> > - goto err;
>> > + return -EINVAL;
>> > }
>> > init_cma_reserved_pageblock(pfn_to_page(base_pfn));
>> > } while (--i);
>> >
>> > + cma->bitmap = kzalloc(bitmap_size, GFP_KERNEL);
>> > + if (!cma->bitmap)
>> > + return -ENOMEM;
>> > +
>> > mutex_init(>lock);
>> > return 0;
>> > -
>> > -err:
>> > - kfree(cma->bitmap);
>> > - return -EINVAL;
>> > }
>> >
>> > static int __init cma_init_reserved_areas(void)
>> > @@ -313,7 +308,7 @@ struct page *cma_alloc(struct cma *cma, int count,
>> > unsigned int align)
>> > struct page *page = NULL;
>> > int ret;
>> >
>> > - if (!cma || !cma->count)
>> > + if (!cma || !cma->count || !cma->bitmap)
>> > return NULL;
>> >
>> > pr_debug("%s(cma %p, count %d, align %d)\n", __func__, (void *)cma,
>
> --
> Regards,
>
> Laurent Pinchart
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 RESEND] perf tools: makes CPUINFO_PROC to array for different kernel version
Hi Arnaldo, A have posted a v3 patch based on your git repository. Please refer to: https://lkml.org/lkml/2014/10/23/711 . Thanks. On 2014/10/24 7:53, Arnaldo Carvalho de Melo wrote: > Em Fri, Oct 24, 2014 at 08:26:13AM +0900, Namhyung Kim escreveu: >> On Wed, 22 Oct 2014 15:40:14 +0800, Wang Nan wrote: >>> After kernel 3.7 (commit b4b8f770eb10a1bccaf8aa0ec1956e2dd7ed1e0a), >>> /proc/cpuinfo replaces 'Processor' to 'model name'. This patch makes >>> CPUINFO_PROC to an array and provides two choices for ARM, makes it >>> compatible for different kernel version. > >>> v1 -> v2: minor changes as suggested by Namhyung Kim: > >>> - Doesn't pass @h and @evlist to __write_cpudesc; >>> - Coding style fix. > >>> Signed-off-by: Wang Nan > >> Acked-by: Namhyung Kim > > So now this will work with older kernels and new ones? Cool, thanks for > working on it, but: > > [acme@ssdandy linux]$ patch -p1 < /wb/1.patch > patching file tools/perf/perf.h > Hunk #1 FAILED at 6. > Hunk #2 FAILED at 15. > Hunk #3 FAILED at 25. > Hunk #4 FAILED at 40. > Hunk #5 FAILED at 74. > Hunk #6 FAILED at 91. > 6 out of 6 hunks FAILED -- saving rejects to file tools/perf/perf.h.rej > patching file tools/perf/util/header.c > Hunk #1 succeeded at 579 (offset 29 lines). > Hunk #2 succeeded at 636 (offset 29 lines). > [acme@ssdandy linux]$ > > [acme@ssdandy linux]$ git log --oneline tools/perf/perf.h | head -10 > 87c43ee perf tools: Export usage string and option table of perf record > 72a128a perf tools: Move callchain config from record_opts to callchain_param > 73a31b7 perf tools: Move ACCESS_ONCE from perf.h header > 82baa0e perf tools: Move sys_perf_event_open function from perf.h > 43599d1 perf tools: Move syscall and arch specific defines from perf.h > 2c83bc0 perf tools: Move perf_call_graph_mode enum from perf.h > 0776eb5 perf tools: Move sample data structures from perf.h > 36446f4 perf tools: Remove PR_TASK_PERF_EVENTS_* from perf.h > 273a0a7 perf tools: Remove asmlinkage define from perf.h > 1b7ae1c perf tools: Remove min define from perf.h > [acme@ssdandy linux]$ > > This is: > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git perf/core > > If you don't have time to fix this up, I'll try to find time tomorrow > and do it. > > - Arnaldo > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PATCHSET 0/5] perf tools: Speed up dwarf callchain post-unwinding for libunwind (v4)
Em Fri, Oct 24, 2014 at 09:44:17AM +0900, Namhyung Kim escreveu: > On Thu, 23 Oct 2014 20:35:42 -0300, Arnaldo Carvalho de Melo wrote: > > I'll push later and will drop you a note, so that you can, please, check > > if the end result is sane. > > Thank you! It should be on my perf/core branch by now. > > Sorry for the slip up, > > No problem. :) :-) - Arnaldo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] perf tools: makes CPUINFO_PROC to array for different kernel version
Em Fri, Oct 24, 2014 at 09:45:26AM +0800, Wang Nan escreveu:
> After kernel 3.7 (commit b4b8f770eb10a1bccaf8aa0ec1956e2dd7ed1e0a),
> /proc/cpuinfo replaces 'Processor' to 'model name'. This patch makes
> CPUINFO_PROC to an array and provides two choices for ARM, makes it
> compatible for different kernel version.
>
> v1 -> v2: minor changes as suggested by Namhyung Kim:
>
> - Doesn't pass @h and @evlist to __write_cpudesc;
> - Coding style fix.
>
> v2 -> v3:
> - Rebase:
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git perf/core
Thanks a lot, applying now.
- Arnaldo
> Signed-off-by: Wang Nan
> Acked-by: Namhyung Kim
> Cc: Arnaldo Carvalho de Melo
> ---
> tools/perf/perf-sys.h| 30 +++---
> tools/perf/util/header.c | 27 +--
> 2 files changed, 36 insertions(+), 21 deletions(-)
>
> diff --git a/tools/perf/perf-sys.h b/tools/perf/perf-sys.h
> index 937e432..a3b13d7 100644
> --- a/tools/perf/perf-sys.h
> +++ b/tools/perf/perf-sys.h
> @@ -13,7 +13,7 @@
> #define wmb()asm volatile("lock; addl $0,0(%%esp)" :::
> "memory")
> #define rmb()asm volatile("lock; addl $0,0(%%esp)" :::
> "memory")
> #define cpu_relax() asm volatile("rep; nop" ::: "memory");
> -#define CPUINFO_PROC "model name"
> +#define CPUINFO_PROC {"model name"}
> #ifndef __NR_perf_event_open
> # define __NR_perf_event_open 336
> #endif
> @@ -30,7 +30,7 @@
> #define wmb()asm volatile("sfence" ::: "memory")
> #define rmb()asm volatile("lfence" ::: "memory")
> #define cpu_relax() asm volatile("rep; nop" ::: "memory");
> -#define CPUINFO_PROC "model name"
> +#define CPUINFO_PROC {"model name"}
> #ifndef __NR_perf_event_open
> # define __NR_perf_event_open 298
> #endif
> @@ -47,14 +47,14 @@
> #define mb() asm volatile ("sync" ::: "memory")
> #define wmb()asm volatile ("sync" ::: "memory")
> #define rmb()asm volatile ("sync" ::: "memory")
> -#define CPUINFO_PROC "cpu"
> +#define CPUINFO_PROC {"cpu"}
> #endif
>
> #ifdef __s390__
> #define mb() asm volatile("bcr 15,0" ::: "memory")
> #define wmb()asm volatile("bcr 15,0" ::: "memory")
> #define rmb()asm volatile("bcr 15,0" ::: "memory")
> -#define CPUINFO_PROC "vendor_id"
> +#define CPUINFO_PROC {"vendor_id"}
> #endif
>
> #ifdef __sh__
> @@ -67,14 +67,14 @@
> # define wmb() asm volatile("" ::: "memory")
> # define rmb() asm volatile("" ::: "memory")
> #endif
> -#define CPUINFO_PROC "cpu type"
> +#define CPUINFO_PROC {"cpu type"}
> #endif
>
> #ifdef __hppa__
> #define mb() asm volatile("" ::: "memory")
> #define wmb()asm volatile("" ::: "memory")
> #define rmb()asm volatile("" ::: "memory")
> -#define CPUINFO_PROC "cpu"
> +#define CPUINFO_PROC {"cpu"}
> #endif
>
> #ifdef __sparc__
> @@ -87,14 +87,14 @@
> #endif
> #define wmb()asm volatile("":::"memory")
> #define rmb()asm volatile("":::"memory")
> -#define CPUINFO_PROC "cpu"
> +#define CPUINFO_PROC {"cpu"}
> #endif
>
> #ifdef __alpha__
> #define mb() asm volatile("mb" ::: "memory")
> #define wmb()asm volatile("wmb" ::: "memory")
> #define rmb()asm volatile("mb" ::: "memory")
> -#define CPUINFO_PROC "cpu model"
> +#define CPUINFO_PROC {"cpu model"}
> #endif
>
> #ifdef __ia64__
> @@ -102,7 +102,7 @@
> #define wmb()asm volatile ("mf" ::: "memory")
> #define rmb()asm volatile ("mf" ::: "memory")
> #define cpu_relax() asm volatile ("hint @pause" ::: "memory")
> -#define CPUINFO_PROC "model name"
> +#define CPUINFO_PROC {"model name"}
> #endif
>
> #ifdef __arm__
> @@ -113,7 +113,7 @@
> #define mb() ((void(*)(void))0x0fa0)()
> #define wmb()((void(*)(void))0x0fa0)()
> #define rmb()((void(*)(void))0x0fa0)()
> -#define CPUINFO_PROC "Processor"
> +#define CPUINFO_PROC {"model name", "Processor"}
> #endif
>
> #ifdef __aarch64__
> @@ -133,28 +133,28 @@
> : "memory")
> #define wmb()mb()
> #define rmb()mb()
> -#define CPUINFO_PROC "cpu model"
> +#define CPUINFO_PROC {"cpu model"}
> #endif
>
> #ifdef __arc__
> #define mb() asm volatile("" ::: "memory")
> #define wmb()asm volatile("" ::: "memory")
> #define rmb()asm volatile("" ::: "memory")
> -#define CPUINFO_PROC "Processor"
> +#define CPUINFO_PROC {"Processor"}
> #endif
>
> #ifdef __metag__
> #define mb() asm volatile("" ::: "memory")
> #define wmb()asm volatile("" ::: "memory")
> #define rmb()asm volatile("" ::: "memory")
> -#define CPUINFO_PROC "CPU"
> +#define CPUINFO_PROC {"CPU"}
> #endif
>
> #ifdef __xtensa__
> #define mb() asm volatile("memw" :::
[PATCH v3] perf tools: makes CPUINFO_PROC to array for different kernel version
After kernel 3.7 (commit b4b8f770eb10a1bccaf8aa0ec1956e2dd7ed1e0a),
/proc/cpuinfo replaces 'Processor' to 'model name'. This patch makes
CPUINFO_PROC to an array and provides two choices for ARM, makes it
compatible for different kernel version.
v1 -> v2: minor changes as suggested by Namhyung Kim:
- Doesn't pass @h and @evlist to __write_cpudesc;
- Coding style fix.
v2 -> v3:
- Rebase:
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git perf/core
Signed-off-by: Wang Nan
Acked-by: Namhyung Kim
Cc: Arnaldo Carvalho de Melo
---
tools/perf/perf-sys.h| 30 +++---
tools/perf/util/header.c | 27 +--
2 files changed, 36 insertions(+), 21 deletions(-)
diff --git a/tools/perf/perf-sys.h b/tools/perf/perf-sys.h
index 937e432..a3b13d7 100644
--- a/tools/perf/perf-sys.h
+++ b/tools/perf/perf-sys.h
@@ -13,7 +13,7 @@
#define wmb() asm volatile("lock; addl $0,0(%%esp)" ::: "memory")
#define rmb() asm volatile("lock; addl $0,0(%%esp)" ::: "memory")
#define cpu_relax()asm volatile("rep; nop" ::: "memory");
-#define CPUINFO_PROC "model name"
+#define CPUINFO_PROC {"model name"}
#ifndef __NR_perf_event_open
# define __NR_perf_event_open 336
#endif
@@ -30,7 +30,7 @@
#define wmb() asm volatile("sfence" ::: "memory")
#define rmb() asm volatile("lfence" ::: "memory")
#define cpu_relax()asm volatile("rep; nop" ::: "memory");
-#define CPUINFO_PROC "model name"
+#define CPUINFO_PROC {"model name"}
#ifndef __NR_perf_event_open
# define __NR_perf_event_open 298
#endif
@@ -47,14 +47,14 @@
#define mb() asm volatile ("sync" ::: "memory")
#define wmb() asm volatile ("sync" ::: "memory")
#define rmb() asm volatile ("sync" ::: "memory")
-#define CPUINFO_PROC "cpu"
+#define CPUINFO_PROC {"cpu"}
#endif
#ifdef __s390__
#define mb() asm volatile("bcr 15,0" ::: "memory")
#define wmb() asm volatile("bcr 15,0" ::: "memory")
#define rmb() asm volatile("bcr 15,0" ::: "memory")
-#define CPUINFO_PROC "vendor_id"
+#define CPUINFO_PROC {"vendor_id"}
#endif
#ifdef __sh__
@@ -67,14 +67,14 @@
# define wmb() asm volatile("" ::: "memory")
# define rmb() asm volatile("" ::: "memory")
#endif
-#define CPUINFO_PROC "cpu type"
+#define CPUINFO_PROC {"cpu type"}
#endif
#ifdef __hppa__
#define mb() asm volatile("" ::: "memory")
#define wmb() asm volatile("" ::: "memory")
#define rmb() asm volatile("" ::: "memory")
-#define CPUINFO_PROC "cpu"
+#define CPUINFO_PROC {"cpu"}
#endif
#ifdef __sparc__
@@ -87,14 +87,14 @@
#endif
#define wmb() asm volatile("":::"memory")
#define rmb() asm volatile("":::"memory")
-#define CPUINFO_PROC "cpu"
+#define CPUINFO_PROC {"cpu"}
#endif
#ifdef __alpha__
#define mb() asm volatile("mb" ::: "memory")
#define wmb() asm volatile("wmb" ::: "memory")
#define rmb() asm volatile("mb" ::: "memory")
-#define CPUINFO_PROC "cpu model"
+#define CPUINFO_PROC {"cpu model"}
#endif
#ifdef __ia64__
@@ -102,7 +102,7 @@
#define wmb() asm volatile ("mf" ::: "memory")
#define rmb() asm volatile ("mf" ::: "memory")
#define cpu_relax()asm volatile ("hint @pause" ::: "memory")
-#define CPUINFO_PROC "model name"
+#define CPUINFO_PROC {"model name"}
#endif
#ifdef __arm__
@@ -113,7 +113,7 @@
#define mb() ((void(*)(void))0x0fa0)()
#define wmb() ((void(*)(void))0x0fa0)()
#define rmb() ((void(*)(void))0x0fa0)()
-#define CPUINFO_PROC "Processor"
+#define CPUINFO_PROC {"model name", "Processor"}
#endif
#ifdef __aarch64__
@@ -133,28 +133,28 @@
: "memory")
#define wmb() mb()
#define rmb() mb()
-#define CPUINFO_PROC "cpu model"
+#define CPUINFO_PROC {"cpu model"}
#endif
#ifdef __arc__
#define mb() asm volatile("" ::: "memory")
#define wmb() asm volatile("" ::: "memory")
#define rmb() asm volatile("" ::: "memory")
-#define CPUINFO_PROC "Processor"
+#define CPUINFO_PROC {"Processor"}
#endif
#ifdef __metag__
#define mb() asm volatile("" ::: "memory")
#define wmb() asm volatile("" ::: "memory")
#define rmb() asm volatile("" ::: "memory")
-#define CPUINFO_PROC "CPU"
+#define CPUINFO_PROC {"CPU"}
#endif
#ifdef __xtensa__
#define mb() asm volatile("memw" ::: "memory")
#define wmb() asm volatile("memw" ::: "memory")
#define rmb() asm volatile("" ::: "memory")
-#define CPUINFO_PROC "core ID"
+#define CPUINFO_PROC {"core ID"}
#endif
#ifdef __tile__
@@ -162,7 +162,7 @@
#define wmb() asm volatile ("mf" ::: "memory")
#define rmb() asm volatile ("mf" ::: "memory")
#define cpu_relax()asm volatile ("mfspr zero, PASS" ::: "memory")
-#define CPUINFO_PROC"model name"
[PATCH net] bpf: split eBPF out of NET
introduce two configs:
- hidden CONFIG_BPF to select eBPF interpreter that classic socket filters
depend on
- visible CONFIG_BPF_SYSCALL (default off) that tracing and sockets can use
that solves several problems:
- tracing and others that wish to use eBPF don't need to depend on NET.
They can use BPF_SYSCALL to allow loading from userspace or select BPF
to use it directly from kernel in NET-less configs.
- in 3.18 programs cannot be attached to events yet, so don't force it on
- when the rest of eBPF infra is there in 3.19+, it's still useful to
switch it off to minimize kernel size
Signed-off-by: Alexei Starovoitov
---
bloat-o-meter on x64 shows:
add/remove: 0/60 grow/shrink: 0/2 up/down: 0/-15601 (-15601)
tested with many different config combinations. Hopefully didn't miss anything.
init/Kconfig| 14 ++
kernel/Makefile |2 +-
kernel/bpf/Makefile |6 +++---
kernel/bpf/core.c |9 +
net/Kconfig |2 +-
5 files changed, 28 insertions(+), 5 deletions(-)
diff --git a/init/Kconfig b/init/Kconfig
index 3ee28ae..340fd92 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1341,6 +1341,10 @@ config SYSCTL_ARCH_UNALIGN_ALLOW
config HAVE_PCSPKR_PLATFORM
bool
+# interpreter that classic socket filters depend on
+config BPF
+ boolean
+
menuconfig EXPERT
bool "Configure standard kernel features (expert users)"
# Unhide debug options, to make the on-by-default options visible
@@ -1521,6 +1525,16 @@ config EVENTFD
If unsure, say Y.
+# syscall, maps, verifier
+config BPF_SYSCALL
+ bool "Enable bpf() system call" if EXPERT
+ select ANON_INODES
+ select BPF
+ default n
+ help
+ Enable the bpf() system call that allows to manipulate eBPF
+ programs and maps via file descriptors.
+
config SHMEM
bool "Use full shmem filesystem" if EXPERT
default y
diff --git a/kernel/Makefile b/kernel/Makefile
index dc5c775..17ea6d4 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -86,7 +86,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/
+obj-$(CONFIG_BPF) += bpf/
obj-$(CONFIG_PERF_EVENTS) += events/
diff --git a/kernel/bpf/Makefile b/kernel/bpf/Makefile
index 4542723..0daf7f6 100644
--- a/kernel/bpf/Makefile
+++ b/kernel/bpf/Makefile
@@ -1,5 +1,5 @@
-obj-y := core.o syscall.o verifier.o
-
+obj-y := core.o
+obj-$(CONFIG_BPF_SYSCALL) += syscall.o verifier.o
ifdef CONFIG_TEST_BPF
-obj-y += test_stub.o
+obj-$(CONFIG_BPF_SYSCALL) += test_stub.o
endif
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index f0c30c5..d6594e4 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -655,3 +655,12 @@ void bpf_prog_free(struct bpf_prog *fp)
schedule_work(>work);
}
EXPORT_SYMBOL_GPL(bpf_prog_free);
+
+/* To execute LD_ABS/LD_IND instructions __bpf_prog_run() may call
+ * skb_copy_bits(), so provide a weak definition of it for NET-less config.
+ */
+int __weak skb_copy_bits(const struct sk_buff *skb, int offset, void *to,
+int len)
+{
+ return -EFAULT;
+}
diff --git a/net/Kconfig b/net/Kconfig
index 6272420..99815b5 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -6,7 +6,7 @@ menuconfig NET
bool "Networking support"
select NLATTR
select GENERIC_NET_UTILS
- select ANON_INODES
+ select BPF
---help---
Unless you really know what you are doing, you should say Y here.
The reason is that some programs need kernel networking support even
--
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 v13 4/5] ARM: dts: add main Thermal info to rk3288
On October 23, 2014 6:08:52 PM PDT, Caesar Wang
wrote:
>Dmitry,
>
>在 2014/10/24 8:46, Dmitry Torokhov 写道:
>> Hi Caesar,
>>
>> On Thu, Oct 23, 2014 at 05:40:06PM +0800, Caesar Wang wrote:
>>> This patch is depend on rk3288-thermal.dtsi,or
>>> it will compile error.
>>>
>>> If the temperature over a period of time High,over 120C
>>> the resulting TSHUT gave CRU module,let it reset
>>> the entire chip,or via GPIO give PMIC.
>>>
>>> Signed-off-by: Caesar Wang
>>> ---
>>> arch/arm/boot/dts/rk3288.dtsi | 21 +
>>> 1 file changed, 21 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/rk3288.dtsi
>b/arch/arm/boot/dts/rk3288.dtsi
>>> index cb18bb4..85fc17a 100644
>>> --- a/arch/arm/boot/dts/rk3288.dtsi
>>> +++ b/arch/arm/boot/dts/rk3288.dtsi
>>> @@ -15,6 +15,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include "skeleton.dtsi"
>>>
>>> / {
>>> @@ -66,6 +67,7 @@
>>> 216000 90
>>> 126000 90
>>> >;
>>> + #cooling-cells = <2>; /* min followed by max */
>>> clock-latency = <4>;
>>> clocks = < ARMCLK>;
>>> };
>>> @@ -346,6 +348,19 @@
>>> status = "disabled";
>>> };
>>>
>>> + tsadc: tsadc@ff28 {
>>> + compatible = "rockchip,rk3288-tsadc";
>>> + reg = <0xff28 0x100>;
>>> + interrupts = ;
>>> + clocks = < SCLK_TSADC>, < PCLK_TSADC>;
>>> + clock-names = "tsadc", "apb_pclk";
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <_out>;
>>> + #thermal-sensor-cells = <1>;
>>> + hw-shut-temp = <12>;
>> I do not think this is a good value. You have (in the other DTS file)
>> passive trip point at 80 and critical (which should result in orderly
>> shutdown) at 125. But here you define hardware-controlled shutdown at
>> 120C, which is backwards. You should have:
>>
>> passive <= critical <= hardware
>Hmmm
>but, the system will shutdown when temperature over critial value,
>there is no chance of triggering the TSHUT.
>
>If the temperature over a period of time High,as we know,
>the resulting TSHUT gave CRU module,let it hot-reset the entire chip,
>or via GPIO give PMIC cold-reset the entire chip.
Having tshut trigger is not the goal, tshut is the measure of last resort. If
we can handle thermal conditions without triggering tshut, we achieved our goal.
Tshut triggering is " oh, crap, nothing we tried works" scenario.
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/7] arm64: dts: Add X-Gene reboot driver dts node
Add X-Gene platform reboot driver dts node.
Signed-off-by: Feng Kan
---
arch/arm64/boot/dts/apm-storm.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/apm-storm.dtsi
b/arch/arm64/boot/dts/apm-storm.dtsi
index a80f2fa..9532aa3 100644
--- a/arch/arm64/boot/dts/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm-storm.dtsi
@@ -103,6 +103,11 @@
#size-cells = <2>;
ranges;
+ scu: system-clk-controller@1700 {
+ compatible = "apm,xgene-scu","syscon";
+ reg = <0x0 0x1700 0x0 0x400>;
+ };
+
clocks {
#address-cells = <2>;
#size-cells = <2>;
@@ -354,6 +359,13 @@
};
};
+ reboot: reboot@1714 {
+ compatible = "syscon-reboot";
+ regmap = <>;
+ offset = <0x14>;
+ mask = <0x1>;
+ };
+
pcie0: pcie@1f2b {
status = "disabled";
device_type = "pci";
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] arm64: dts: Add APM X-Gene USB 2.0 DTS node
Sorry, messed up the title will resend
On Thu, Oct 23, 2014 at 6:24 PM, Feng Kan wrote:
> This parch adds the device tree nodes for APM X-Gnene USB host controller.
> Since X-Gene SOC supports maximum 2 USB ports, 2 dts node are added.
>
> Signed-off-by: Bao Truong
> Signed-off-by: Feng Kan
> ---
> arch/arm64/boot/dts/apm-storm.dtsi | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/apm-storm.dtsi
> b/arch/arm64/boot/dts/apm-storm.dtsi
> index 3eef74b..a80f2fa 100644
> --- a/arch/arm64/boot/dts/apm-storm.dtsi
> +++ b/arch/arm64/boot/dts/apm-storm.dtsi
> @@ -587,6 +587,20 @@
> phy-names = "sata-phy";
> };
>
> + usb0: dwusb@1900 {
> + status = "disabled";
> + compatible = "xhci-platform";
> + reg = <0x0 0x1900 0x0 0x10>;
> + interrupts = <0x0 0x89 0x4>;
> + };
> +
> + usb1: dwusb@1980 {
> + status = "disabled";
> + compatible = "xhci-platform";
> + reg = <0x0 0x1980 0x0 0x10>;
> + interrupts = <0x0 0x8a 0x4>;
> + };
> +
> rtc: rtc@1051 {
> compatible = "apm,xgene-rtc";
> reg = <0x0 0x1051 0x0 0x400>;
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/7] arm64: dts: Add APM X-Gene SoC GFC GPIO controller DTS entries
Add the flash controller muxed gpio dts node for APM X-Gene SoC platform.
Signed-off-by: Feng Kan
---
arch/arm64/boot/dts/apm-storm.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/apm-storm.dtsi
b/arch/arm64/boot/dts/apm-storm.dtsi
index d84cf33..b2e6068 100644
--- a/arch/arm64/boot/dts/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm-storm.dtsi
@@ -540,6 +540,13 @@
};
};
+ gfcgpio: gpio0@1701c000 {
+ compatible = "apm,xgene-gpio";
+ reg = <0x0 0x1701c000 0x0 0x40>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
phy1: phy@1f21a000 {
compatible = "apm,xgene-phy";
reg = <0x0 0x1f21a000 0x0 0x100>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7] arm64: dts: Add Designware GPIO dts binding to APM X-Gene platform
Add Designware GPIO dts binding to APM X-Gene platform
Signed-off-by: Feng Kan
---
arch/arm64/boot/dts/apm-storm.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/apm-storm.dtsi
b/arch/arm64/boot/dts/apm-storm.dtsi
index 9532aa3..d84cf33 100644
--- a/arch/arm64/boot/dts/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm-storm.dtsi
@@ -525,6 +525,21 @@
interrupts = <0x0 0x4f 0x4>;
};
+ dwgpio: dwgpio@1c024000 {
+ compatible = "snps,dw-apb-gpio";
+ reg = <0x0 0x1c024000 0x0 0x1000>;
+ reg-io-width = <4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ porta: gpio-controller@0 {
+ compatible = "snps,dw-apb-gpio-port";
+ gpio-controller;
+ snps,nr-gpios = <32>;
+ reg = <0>;
+ };
+ };
+
phy1: phy@1f21a000 {
compatible = "apm,xgene-phy";
reg = <0x0 0x1f21a000 0x0 0x100>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/7] Documentation: arm: pmu: Add Potenza PMU binding
This patch documents the compatible string for APM X-Gene Potenza CPU's PMU. Signed-off-by: Vinayak Kale Signed-off-by: Feng Kan --- Documentation/devicetree/bindings/arm/pmu.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/pmu.txt b/Documentation/devicetree/bindings/arm/pmu.txt index 75ef91d..6d268b3 100644 --- a/Documentation/devicetree/bindings/arm/pmu.txt +++ b/Documentation/devicetree/bindings/arm/pmu.txt @@ -7,6 +7,7 @@ representation in the device tree should be done as under:- Required properties: - compatible : should be one of + "apm,potenza-pmu" "arm,armv8-pmuv3" "arm,cortex-a17-pmu" "arm,cortex-a15-pmu" -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/7] arm64: dts: Add PMU node for APM X-Gene Storm SOC
This patch adds the PMU device tree node for APM X-Gene Storm SOC.
Signed-off-by: Vinayak Kale
Signed-off-by: Feng Kan
---
arch/arm64/boot/dts/apm-storm.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/apm-storm.dtsi
b/arch/arm64/boot/dts/apm-storm.dtsi
index b2e6068..85d2dd7 100644
--- a/arch/arm64/boot/dts/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm-storm.dtsi
@@ -97,6 +97,11 @@
clock-frequency = <5000>;
};
+ pmu {
+ compatible = "apm,potenza-pmu", "arm,armv8-pmuv3";
+ interrupts = <1 12 0xff04>;
+ };
+
soc {
compatible = "simple-bus";
#address-cells = <2>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/7] arm64: dts: Add APM X-Gene USB 2.0 DTS node
This parch adds the device tree nodes for APM X-Gnene USB host controller.
Since X-Gene SOC supports maximum 2 USB ports, 2 dts node are added.
Signed-off-by: Bao Truong
Signed-off-by: Feng Kan
---
arch/arm64/boot/dts/apm-storm.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/apm-storm.dtsi
b/arch/arm64/boot/dts/apm-storm.dtsi
index 3eef74b..a80f2fa 100644
--- a/arch/arm64/boot/dts/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm-storm.dtsi
@@ -587,6 +587,20 @@
phy-names = "sata-phy";
};
+ usb0: dwusb@1900 {
+ status = "disabled";
+ compatible = "xhci-platform";
+ reg = <0x0 0x1900 0x0 0x10>;
+ interrupts = <0x0 0x89 0x4>;
+ };
+
+ usb1: dwusb@1980 {
+ status = "disabled";
+ compatible = "xhci-platform";
+ reg = <0x0 0x1980 0x0 0x10>;
+ interrupts = <0x0 0x8a 0x4>;
+ };
+
rtc: rtc@1051 {
compatible = "apm,xgene-rtc";
reg = <0x0 0x1051 0x0 0x400>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/7] Documentation: arm64: add SCU dts binding documentation to linux kernel
This add documentation for the SCU system clock unit device tree binding
to the kernel.
Signed-off-by: Feng Kan
---
Documentation/devicetree/bindings/arm/apm/scu.txt | 17 +
1 file changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/apm/scu.txt
diff --git a/Documentation/devicetree/bindings/arm/apm/scu.txt
b/Documentation/devicetree/bindings/arm/apm/scu.txt
new file mode 100644
index 000..b45be06
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/apm/scu.txt
@@ -0,0 +1,17 @@
+APM X-GENE SoC series SCU Registers
+
+This system clock unit contain various register that control block resets,
+clock enable/disables, clock divisors and other deepsleep registers.
+
+Properties:
+ - compatible : should contain two values. First value must be:
+ - "apm,xgene-scu"
+ second value must be always "syscon".
+
+ - reg : offset and length of the register set.
+
+Example :
+ scu: system-clk-controller@1700 {
+ compatible = "apm,xgene-scu","syscon";
+ reg = <0x0 0x1700 0x0 0x400>;
+ };
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/7] APM X-Gene SoC platform device tree cleanup
This sums up the dts changes of the recent committed drivers into the kernel. This will grant PMU, reboot, USB and gpio functionalities to the platform. Feng Kan (7): arm64: dts: Add APM X-Gene USB 2.0 DTS node Documentation: arm64: add SCU dts binding documentation to linux kernel arm64: dts: Add X-Gene reboot driver dts node arm64: dts: Add Designware GPIO dts binding to APM X-Gene platform arm64: dts: Add APM X-Gene SoC GFC GPIO controller DTS entries Documentation: arm: pmu: Add Potenza PMU binding arm64: dts: Add PMU node for APM X-Gene Storm SOC Documentation/devicetree/bindings/arm/apm/scu.txt | 17 Documentation/devicetree/bindings/arm/pmu.txt | 1 + arch/arm64/boot/dts/apm-storm.dtsi| 53 +++ 3 files changed, 71 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/apm/scu.txt -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v13 4/5] ARM: dts: add main Thermal info to rk3288
Dmitry,
在 2014/10/24 8:46, Dmitry Torokhov 写道:
Hi Caesar,
On Thu, Oct 23, 2014 at 05:40:06PM +0800, Caesar Wang wrote:
This patch is depend on rk3288-thermal.dtsi,or
it will compile error.
If the temperature over a period of time High,over 120C
the resulting TSHUT gave CRU module,let it reset
the entire chip,or via GPIO give PMIC.
Signed-off-by: Caesar Wang
---
arch/arm/boot/dts/rk3288.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index cb18bb4..85fc17a 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include "skeleton.dtsi"
/ {
@@ -66,6 +67,7 @@
216000 90
126000 90
>;
+ #cooling-cells = <2>; /* min followed by max */
clock-latency = <4>;
clocks = < ARMCLK>;
};
@@ -346,6 +348,19 @@
status = "disabled";
};
+ tsadc: tsadc@ff28 {
+ compatible = "rockchip,rk3288-tsadc";
+ reg = <0xff28 0x100>;
+ interrupts = ;
+ clocks = < SCLK_TSADC>, < PCLK_TSADC>;
+ clock-names = "tsadc", "apb_pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <_out>;
+ #thermal-sensor-cells = <1>;
+ hw-shut-temp = <12>;
I do not think this is a good value. You have (in the other DTS file)
passive trip point at 80 and critical (which should result in orderly
shutdown) at 125. But here you define hardware-controlled shutdown at
120C, which is backwards. You should have:
passive <= critical <= hardware
Hmmm
but, the system will shutdown when temperature over critial value,
there is no chance of triggering the TSHUT.
If the temperature over a period of time High,as we know,
the resulting TSHUT gave CRU module,let it hot-reset the entire chip,
or via GPIO give PMIC cold-reset the entire chip.
Thanks.
--
Best regards,
Caesar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] tracing, function_graph: fix micro seconds notation in comment
On Fri, Oct 24, 2014 at 09:20:11AM +0900, Namhyung Kim wrote:
> Hi Byungchul,
>
> On Thu, 23 Oct 2014 17:17:21 +0900, byungchul park wrote:
> > From: Byungchul Park
> >
> > Usually, "msecs" notation means milli-seconds, and "usecs" notation
> > means micro-seconds. Since the unit used in the code is
> > micro-seconds, the notation should be replaced from msecs to usecs.
> > This confusing notation prevents us from understanding the code
> > correctly.
> >
> > Signed-off-by: Byungchul Park
> > ---
> > kernel/trace/trace_functions_graph.c |4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/kernel/trace/trace_functions_graph.c
> > b/kernel/trace/trace_functions_graph.c
> > index f0a0c98..c18a1e3 100644
> > --- a/kernel/trace/trace_functions_graph.c
> > +++ b/kernel/trace/trace_functions_graph.c
> > @@ -822,10 +822,10 @@ print_graph_duration(unsigned long long duration,
> > struct trace_seq *s,
> >
> > /* Signal a overhead of time execution to the output */
> > if (flags & TRACE_GRAPH_PRINT_OVERHEAD) {
> > - /* Duration exceeded 100 msecs */
> > + /* Duration exceeded 100 usecs */
> > if (duration > 10ULL)
> > ret = trace_seq_puts(s, "! ");
> > - /* Duration exceeded 10 msecs */
> > + /* Duration exceeded 10 usecs */
> > else if (duration > 1ULL)
>
> I thought the duration was in usec, but it seems not, it's in nsec, hmm.
> Then this exceeding 10/100 usec is not meaningful - what about increaing
> numbers in the conditional so that it can match to the comment? That
> will eliminate the need of the patch 2.
The approach you suggested also looks good to me. But I just wonder if it
would be ok even if it changes meaning of the marks, "!", "+", because the
marks have used with the meaning of exceeding 10/100 usec until now.
Isn't there anything wrong with increasing numbers in the conditions? :)
>
> Also I think msecs_str in trace_print_graph_duration() should be renamed
> to usecs_str.
I agree. It should be also renamed. Such words made me hard to understand
the code correctly. :(
>
> Thanks,
> Namhyung
>
>
> > ret = trace_seq_puts(s, "+ ");
> > }
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv1 5/8] cgroup: introduce cgroup namespaces
I will include the suggested changes in the new patchset. Some comments inline.
On Thu, Oct 16, 2014 at 9:37 AM, Serge E. Hallyn wrote:
> Quoting Aditya Kali (adityak...@google.com):
>> Introduce the ability to create new cgroup namespace. The newly created
>> cgroup namespace remembers the 'struct cgroup *root_cgrp' at the point
>> of creation of the cgroup namespace. The task that creates the new
>> cgroup namespace and all its future children will now be restricted only
>> to the cgroup hierarchy under this root_cgrp.
>> The main purpose of cgroup namespace is to virtualize the contents
>> of /proc/self/cgroup file. Processes inside a cgroup namespace
>> are only able to see paths relative to their namespace root.
>> This allows container-tools (like libcontainer, lxc, lmctfy, etc.)
>> to create completely virtualized containers without leaking system
>> level cgroup hierarchy to the task.
>> This patch only implements the 'unshare' part of the cgroupns.
>>
>> Signed-off-by: Aditya Kali
>
> I'm not sure that the CONFIG_CGROUP_NS is worthwhile. If you already
> have cgroups in the kernel this won't add much in the way of memory
> usage, right? And I think the 'experimental' argument has long since
> been squashed. So I'd argue for simplifying this patch by removing
> CONFIG_CGROUP_NS.
>
With no pinning involved, I think its safe to enable the feature
without needing a config option. Removed it from next version. This
feature is now implicitly available with CONFIG_CGROUPS.
> (more below)
>
>> ---
>> fs/proc/namespaces.c | 3 +
>> include/linux/cgroup.h | 18 +-
>> include/linux/cgroup_namespace.h | 62 +++
>> include/linux/nsproxy.h | 2 +
>> include/linux/proc_ns.h | 4 ++
>> init/Kconfig | 9 +++
>> kernel/Makefile | 1 +
>> kernel/cgroup.c | 11
>> kernel/cgroup_namespace.c| 128
>> +++
>> kernel/fork.c| 2 +-
>> kernel/nsproxy.c | 19 +-
>> 11 files changed, 255 insertions(+), 4 deletions(-)
>>
>> diff --git a/fs/proc/namespaces.c b/fs/proc/namespaces.c
>> index 8902609..e04ed4b 100644
>> --- a/fs/proc/namespaces.c
>> +++ b/fs/proc/namespaces.c
>> @@ -32,6 +32,9 @@ static const struct proc_ns_operations *ns_entries[] = {
>> _operations,
>> #endif
>> _operations,
>> +#ifdef CONFIG_CGROUP_NS
>> + _operations,
>> +#endif
>> };
>>
>> static const struct file_operations ns_file_operations = {
>> diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
>> index 4a0eb2d..aa86495 100644
>> --- a/include/linux/cgroup.h
>> +++ b/include/linux/cgroup.h
>> @@ -22,6 +22,8 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>>
>> #ifdef CONFIG_CGROUPS
>>
>> @@ -460,6 +462,13 @@ struct cftype {
>> #endif
>> };
>>
>> +struct cgroup_namespace {
>> + atomic_tcount;
>> + unsigned intproc_inum;
>> + struct user_namespace *user_ns;
>> + struct cgroup *root_cgrp;
>> +};
>> +
>> extern struct cgroup_root cgrp_dfl_root;
>> extern struct css_set init_css_set;
>>
>> @@ -584,10 +593,17 @@ static inline int cgroup_name(struct cgroup *cgrp,
>> char *buf, size_t buflen)
>> return kernfs_name(cgrp->kn, buf, buflen);
>> }
>>
>> +static inline char * __must_check cgroup_path_ns(struct cgroup_namespace
>> *ns,
>> + struct cgroup *cgrp, char
>> *buf,
>> + size_t buflen)
>> +{
>> + return kernfs_path_from_node(ns->root_cgrp->kn, cgrp->kn, buf, buflen);
>> +}
>> +
>> static inline char * __must_check cgroup_path(struct cgroup *cgrp, char
>> *buf,
>> size_t buflen)
>> {
>> - return kernfs_path(cgrp->kn, buf, buflen);
>> + return cgroup_path_ns(current->nsproxy->cgroup_ns, cgrp, buf, buflen);
>> }
>>
>> static inline void pr_cont_cgroup_name(struct cgroup *cgrp)
>> diff --git a/include/linux/cgroup_namespace.h
>> b/include/linux/cgroup_namespace.h
>> new file mode 100644
>> index 000..9f637fe
>> --- /dev/null
>> +++ b/include/linux/cgroup_namespace.h
>> @@ -0,0 +1,62 @@
>> +#ifndef _LINUX_CGROUP_NAMESPACE_H
>> +#define _LINUX_CGROUP_NAMESPACE_H
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +extern struct cgroup_namespace init_cgroup_ns;
>> +
>> +static inline struct cgroup *task_cgroupns_root(struct task_struct *tsk)
>> +{
>> + return tsk->nsproxy->cgroup_ns->root_cgrp;
>
> Per the rules in nsproxy.h, you should be taking the task_lock here.
>
> (If you are making assumptions about tsk then you need to state them
> here - I only looked quickly enough that you pass in 'leader')
>
In the new version of the patch, we call this function only for the
'current' task. As per nsproxy.h, no special precautions needed when
Re: [PATCH v13 1/5] thermal: rockchip: add driver for thermal
Hi Caesar,
On Thu, Oct 23, 2014 at 05:40:03PM +0800, Caesar Wang wrote:
> Thermal is TS-ADC Controller module supports
> user-defined mode and automatic mode.
>
> User-defined mode refers,TSADC all the control signals entirely by
> software writing to register for direct control.
>
> Automaic mode refers to the module automatically poll TSADC output,
> and the results were checked.If you find that the temperature High
> in a period of time,an interrupt is generated to the processor
> down-measures taken;If the temperature over a period of time High,
> the resulting TSHUT gave CRU module,let it reset the entire chip,
> or via GPIO give PMIC.
>
> Signed-off-by: zhaoyifeng
> Signed-off-by: Caesar Wang
> ---
> drivers/thermal/Kconfig| 9 +
> drivers/thermal/Makefile | 1 +
> drivers/thermal/rockchip_thermal.c | 693
> +
> 3 files changed, 703 insertions(+)
> create mode 100644 drivers/thermal/rockchip_thermal.c
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index ef5587f..5efcf73 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -133,6 +133,15 @@ config SPEAR_THERMAL
> Enable this to plug the SPEAr thermal sensor driver into the Linux
> thermal framework.
>
> +config ROCKCHIP_THERMAL
> + tristate "Rockchip thermal driver"
> + depends on ARCH_ROCKCHIP
> + help
> + Rockchip thermal driver provides support for Temperature sensor
> + ADC (TS-ADC) found on Rockchip SoCs. It supports one critical
> + trip point. Cpufreq is used as the cooling device and will throttle
> + CPUs when the Temperature crosses the passive trip point.
> +
> config RCAR_THERMAL
> tristate "Renesas R-Car thermal driver"
> depends on ARCH_SHMOBILE || COMPILE_TEST
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 31e232f..21da0a8 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -19,6 +19,7 @@ thermal_sys-$(CONFIG_CPU_THERMAL) += cpu_cooling.o
>
> # platform thermal drivers
> obj-$(CONFIG_SPEAR_THERMAL) += spear_thermal.o
> +obj-$(CONFIG_ROCKCHIP_THERMAL) += rockchip_thermal.o
> obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o
> obj-$(CONFIG_KIRKWOOD_THERMAL) += kirkwood_thermal.o
> obj-y+= samsung/
> diff --git a/drivers/thermal/rockchip_thermal.c
> b/drivers/thermal/rockchip_thermal.c
> new file mode 100644
> index 000..6705981
> --- /dev/null
> +++ b/drivers/thermal/rockchip_thermal.c
> @@ -0,0 +1,693 @@
> +/*
> + * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope 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
> +
> +/**
> + * If the temperature over a period of time High,
> + * the resulting TSHUT gave CRU module,let it reset the entire chip,
> + * or via GPIO give PMIC.
> + */
> +enum tshut_mode {
> + TSHUT_MODE_CRU = 0,
> + TSHUT_MODE_GPIO,
> +};
> +
> +/**
> + * the system Temperature Sensors tshut(tshut) polarity
> + * the bit 8 is tshut polarity.
> + * 0: low active, 1: high active
> + */
> +enum tshut_polarity {
> + TSHUT_LOW_ACTIVE = 0,
> + TSHUT_HIGH_ACTIVE,
> +};
> +
> +/**
> + * The system has three Temperature Sensors. channel 0 is reserved,
> + * channel 1 is for CPU, and channel 2 is for GPU.
> + */
> +enum sensor_id {
> + SENSOR_CPU = 1,
> + SENSOR_GPU,
> +};
> +
> +
> +struct rockchip_tsadc_chip {
> + long hw_shut_temp;
> + enum tshut_mode tshut_mode;
> + enum tshut_polarity tshut_polarity;
> +
> + /* Chip-wide methods */
> + void (*initialize)(void __iomem *reg, enum tshut_polarity p);
> + void (*irq_ack)(void __iomem *reg);
> +
> + /* Per-sensor methods */
> + int (*get_temp)(int chn, void __iomem *reg, long *temp);
> + void (*set_alarm_temp)(int chn, void __iomem *reg, long temp);
> + void (*set_tshut_temp)(int chn, void __iomem *reg, long temp);
> + void (*set_tshut_mode)(int chn, void __iomem *reg, enum tshut_mode m);
> + void (*control)(int chn, void __iomem *reg, bool on);
> +};
> +
> +struct rockchip_thermal_sensor {
> + struct rockchip_thermal_data *thermal;
> + struct thermal_zone_device *tzd;
> + enum sensor_id id;
> +};
> +
> +#define NUM_SENSORS 2 /* Ignore unused sensor 0 */
> +
> +struct rockchip_thermal_data {
> + const struct rockchip_tsadc_chip *chip;
> +
Re: [PATCH v3 8/8] clk: Add floor and ceiling constraints to clock rates
On 10/14/2014 06:27 AM, Tomeu Vizoso wrote:
> On 11 October 2014 01:55, Stephen Boyd wrote:
>> On 10/09, Tomeu Vizoso wrote:
>>> +{
>>> + int ret;
>>> +
>>> + clk_prepare_lock();
>>> +
>>> + clk->floor_constraint = rate;
>> No check for ceiling being less than floor?
> No, otherwise the calling code would have to be very careful to set
> both constraints in the correct order based on the current and next
> values. In practice I expect a given consumer to either set a floor or
> a constraint, but not both.
I totally missed this. Why can't we set the ceiling to ULONG_MAX when
the clock is created? That way we can drop the if check in the
aggregation logic for a 0 valued ceiling and then we can add the ceiling
being less than floor check here too?
>
>
>>> +
>>> + WARN(rate > 0 && rate < clk->floor_constraint,
>>> + "clk %s dev %s con %s: new ceiling %lu lower than existing floor
>>> %lu\n",
>>> + clk->core->name, clk->dev_id, clk->con_id, rate,
>>> + clk->floor_constraint);
>>> +
>>> + clk->ceiling_constraint = rate;
>>> + ret = clk_set_rate(clk, clk_get_rate(clk));
>> Why not just pass 0 as the second argument? The same comment
>> applies in the floor function.
> Both behaviours seem equally correct to me, but wonder if it wouldn't
> be better to store the rate that was last set explicitly with set_rate
> and try to reapply that one after every update to the constraints,
> instead of the current rate, or 0/INT_MAX.
>
>
>> This leads to another question though. What does it means for a
>> per-user clock to be disabled and change it's floor or ceiling?
>> Should that count in the aggregation logic?
> Per-user clocks don't get disabled, the whole clock does (but we can
> use per-user clk information to provide better debug information about
> unbalanced calls to prepare and enable).
Ok.
>> So far we haven't required drivers to explicitly call
>> clk_set_rate() with 0 so they can "drop" their rate request
>> because there isn't any other user and disabling the clock is
>> pretty much the same. With multiple users it looks like we're
>> going to require them to set the floor or ceiling to 0 or INT_MAX
>> if they want to remove their request. Alternatively we could
>> track the prepare/unprepare state of the per-user clock and drop
>> the constraint when that instance is unprepared (or reapply it
>> when prepared). It's pretty much a semantic difference, but one
>> benefit would be that we don't have to make two (or three?) calls
>> to the clock framework if we want to drop the rate constraints
>> and disable the clock.
> In my mind this is not such an issue because I view clock constraints
> as attributes of the per-user clks, while the enable and prepare
> states and the actual rate are attributes of the global clock
> instance.
>
>
Alright, I just want to make sure we thought about it. I'll try to think
of any reason for this behavior and if I don't think of anything I'm
happy with the way things are.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 0/7] ARM: kprobes: enable OPTPROBES for ARM 32.
(2014/10/22 20:31), Wang Nan wrote: > Previous 5 version of ARM OPTPROBES patches are unable to deal with > stack storing instructions correctly. V5 patches disallow optimizing > every protential stack store instructions based on pessimistic > assumption. Which, as Tixy comments, 'excludes the main use of > kprobes'. (https://lkml.org/lkml/2014/8/29/117 ) > > The main obstacle which prevents us from computing stack requirement is > the missing of per-instruction decoder in probes_decode_insn() and its > friends. Only part of instructions have their decoders (and not in > each case). > > In this patch series, I propose 'checker', which allows us define > functions for each type of instruction, extract more information. Stack > consumption computing is an example. Checker can be further employed to > determine whether one instruction is possible to execute directy in > optimized kprobe. I'd like to expand current checker framework by > chaining checkers together. After that, I believe most of ARM > instructions can be executed directly like x86, kprobe performace can be > improved. > > The first 3 patches introduces checker. After that, patch 4/7 checks > stack requirement for probed instructions. Patches 5/7 - 7/7 are similar > to patch v5, except: > > 1. As Tixy proposed, unoptimized probes are also suffer from stack > problem (https://lkml.org/lkml/2014/9/1/548 ). Commit d30a0c8b saves > 64 bytes for them, but for instruction use register addressing (like > 'str r0, [sp, r1]'), 64 bytes are unsafe. Patch 5/7 prohibit such > probing according to stack information collected by checker. By the way, this sounds like a bugfix rather than an improvement. Is it possible to separate 1/7-5/7 as a bugfix series? I think those should go to 3.18. Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.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 resend] mips: add arch_trigger_all_cpu_backtrace() function
Currently, arch_trigger_all_cpu_backtrace() is defined in only x86 and sparc
which has nmi interrupt.
But in case of softlockup not a hadrlockup, it could be possible to dump
backtrace of all cpus.
And this could be helpful for debugging.
for example, if system has 2 cpus.
CPU 0 CPU 1
acquire read_lock()
try to do write_lock()
,,,
missing read_unlock()
In this case, dump_stack() print only backtrace for "CPU 0".
If CPU1's calltrace is printed it's very helpful.
This patch adds arch_trigger_all_cpu_backtrace() for mips architecture.
And this enables when softlockup_all_cpu_backtrace is equalt to 1 and
softlock is occurred to dump all cpu's backtrace.
Signed-off-by: Eunbong Song
---
arch/mips/include/asm/irq.h |3 +++
arch/mips/kernel/process.c | 18 ++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/mips/include/asm/irq.h b/arch/mips/include/asm/irq.h
index 39f07ae..5a4e1bb 100644
--- a/arch/mips/include/asm/irq.h
+++ b/arch/mips/include/asm/irq.h
@@ -48,4 +48,7 @@ extern int cp0_compare_irq;
extern int cp0_compare_irq_shift;
extern int cp0_perfcount_irq;
+void arch_trigger_all_cpu_backtrace(bool);
+#define arch_trigger_all_cpu_backtrace arch_trigger_all_cpu_backtrace
+
#endif /* _ASM_IRQ_H */
diff --git a/arch/mips/kernel/process.c b/arch/mips/kernel/process.c
index 636b074..5801f21 100644
--- a/arch/mips/kernel/process.c
+++ b/arch/mips/kernel/process.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_HOTPLUG_CPU
void arch_cpu_idle_dead(void)
@@ -532,3 +533,20 @@ unsigned long arch_align_stack(unsigned long sp)
return sp & ALMASK;
}
+
+static void arch_dump_stack(void *info)
+{
+ struct pt_regs *regs;
+
+ regs = get_irq_regs();
+
+ if (regs)
+ show_regs(regs);
+
+ dump_stack();
+}
+
+void arch_trigger_all_cpu_backtrace(bool include_self)
+{
+ smp_call_function(arch_dump_stack, NULL, 1);
+}
--
1.7.0.1
N떑꿩�r툤y鉉싕b쾊Ф푤v�^�)頻{.n�+돴쪐{콗喩zX㎍썳變}찠꼿쟺�:+v돣�쳭喩zZ+�+zf＂톒쉱�~넮녬i鎬z� 췿ⅱ�?솳鈺�&�)刪f뷌^j푹y쬶끷@A첺뛴
0띠h��뭝
Re: [PATCH v13 3/5] ARM: dts: add RK3288 Thermal data
Hi Caesar,
On Thu, Oct 23, 2014 at 05:40:05PM +0800, Caesar Wang wrote:
> This patch changes a dtsi file to contain the thermal data
> on RK3288 and later SoCs. This data will
> enable a thermal shutdown over 125C.
>
> Signed-off-by: Caesar Wang
> ---
> arch/arm/boot/dts/rk3288-thermal.dtsi | 65
> +++
> 1 file changed, 65 insertions(+)
> create mode 100644 arch/arm/boot/dts/rk3288-thermal.dtsi
>
> diff --git a/arch/arm/boot/dts/rk3288-thermal.dtsi
> b/arch/arm/boot/dts/rk3288-thermal.dtsi
> new file mode 100644
> index 000..c361262
> --- /dev/null
> +++ b/arch/arm/boot/dts/rk3288-thermal.dtsi
> @@ -0,0 +1,65 @@
> +/*
> + * Device Tree Source for RK3288 SoC thermal
> + *
> + * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +#include
> +
> +reserve_thermal: reserve_thermal {
> + polling-delay-passive = <500>; /* milliseconds */
> + polling-delay = <1000>; /* milliseconds */
> +
> + /* sensor ID */
> + thermal-sensors = < 0>;
> +
> +};
> +
> +cpu_thermal: cpu_thermal {
> + polling-delay-passive = <500>; /* milliseconds */
> + polling-delay = <1000>; /* milliseconds */
Given that the hardware supports alarm interrupts I think we should be
able to lower polling frequency. I'd say 5 seconds for polling-delay and
1 second for when we trip over passive point?
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] devicetree: bindings: Add vendor prefix for Micron Technology Co., Ltd.
This patch is used to add vendor prefix for Micron Technology Inc in the vendor-prefixes.txt file. Micron Technology, Inc. is an American multinational corporation based in Boise, Idaho, best known for producing many forms of semiconductor devices. This includes DRAM, SDRAM, flash memory, eMMC and SSDs. Signed-off-by: bean huo --- .../devicetree/bindings/vendor-prefixes.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 723999d..a7bbf6e 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -92,6 +92,7 @@ maxim Maxim Integrated Products mediatek MediaTek Inc. micrel Micrel Inc. microchip Microchip Technology Inc. +micron Micron Technology Inc. mitsubishi Mitsubishi Electric Corporation mosaixtech Mosaix Technologies, Inc. moxa Moxa -- 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 v13 4/5] ARM: dts: add main Thermal info to rk3288
Hi Caesar,
On Thu, Oct 23, 2014 at 05:40:06PM +0800, Caesar Wang wrote:
> This patch is depend on rk3288-thermal.dtsi,or
> it will compile error.
>
> If the temperature over a period of time High,over 120C
> the resulting TSHUT gave CRU module,let it reset
> the entire chip,or via GPIO give PMIC.
>
> Signed-off-by: Caesar Wang
> ---
> arch/arm/boot/dts/rk3288.dtsi | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
> index cb18bb4..85fc17a 100644
> --- a/arch/arm/boot/dts/rk3288.dtsi
> +++ b/arch/arm/boot/dts/rk3288.dtsi
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
> #include "skeleton.dtsi"
>
> / {
> @@ -66,6 +67,7 @@
>216000 90
>126000 90
> >;
> + #cooling-cells = <2>; /* min followed by max */
> clock-latency = <4>;
> clocks = < ARMCLK>;
> };
> @@ -346,6 +348,19 @@
> status = "disabled";
> };
>
> + tsadc: tsadc@ff28 {
> + compatible = "rockchip,rk3288-tsadc";
> + reg = <0xff28 0x100>;
> + interrupts = ;
> + clocks = < SCLK_TSADC>, < PCLK_TSADC>;
> + clock-names = "tsadc", "apb_pclk";
> + pinctrl-names = "default";
> + pinctrl-0 = <_out>;
> + #thermal-sensor-cells = <1>;
> + hw-shut-temp = <12>;
I do not think this is a good value. You have (in the other DTS file)
passive trip point at 80 and critical (which should result in orderly
shutdown) at 125. But here you define hardware-controlled shutdown at
120C, which is backwards. You should have:
passive <= critical <= hardware
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHSET 0/5] perf tools: Speed up dwarf callchain post-unwinding for libunwind (v4)
On Thu, 23 Oct 2014 20:35:42 -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Oct 22, 2014 at 10:34:27AM +0900, Namhyung Kim escreveu:
>> Hi Arnaldo,
>>
>> On Wed, 15 Oct 2014 17:06:30 -0300, Arnaldo Carvalho de Melo wrote:
>> > Next time please run: (I'm fixing this up this time)
>> >
>> > [acme@zoo linux]$ time make -C tools/perf build-test
>> ...
>> > In file included from util/machine.c:14:0:
>> > util/unwind.h: In function ‘unwind__prepare_access’:
>> > util/unwind.h:47:57: error: unused parameter ‘thread’
>> > [-Werror=unused-parameter]
>> > static inline int unwind__prepare_access(struct thread *thread)
>> > ^
>> > util/unwind.h: In function ‘unwind__finish_access’:
>> > util/unwind.h:52:57: error: unused parameter ‘thread’
>> > [-Werror=unused-parameter]
>> > static inline void unwind__finish_access(struct thread *thread) {}
>> > ^
>> > cc1: all warnings being treated as errors
>> > make[3]: *** [util/machine.o] Error 1
>> > make[3]: *** Waiting for unfinished jobs
>> > make[2]: *** [all] Error 2
>> > test: test -x ./perf
>> > make[1]: *** [make_no_libelf] Error 1
>> > make: *** [build-test] Error 2
>> > make: Leaving directory `/home/git/linux/tools/perf'
>>
>> So it seems you didn't include the patch 3/5 which is the key of this
>> series.. Could you please check it again?
>
> Yeah, I'm adding it now, and in this case as well the __maybe_unused was
> missing, added.
It was my bad to miss the annotation, sorry.
>
> I'll push later and will drop you a note, so that you can, please, check
> if the end result is sane.
Thank you!
> Sorry for the slip up,
No problem. :)
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 4/5] perf tools: Add support for exclusive option
Hi Arnaldo,
On Thu, 23 Oct 2014 17:29:48 -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Oct 23, 2014 at 02:05:08PM +0900, Masami Hiramatsu escreveu:
>> (2014/10/23 0:15), Namhyung Kim wrote:
>> > Some options cannot be used at the same time. To handle such options
>> > add a new PARSE_OPT_EXCLUSIVE flag and show error message if more than
>> > one of them is used.
>>
>> Looks useful for me :)
>>
>> Reviewed-by: Masami Hiramatsu
>>
>> I just have a comment below;
>>
>> > @@ -360,19 +378,21 @@ int parse_options_step(struct parse_opt_ctx_t *ctx,
>> >}
>> >
>> >if (arg[1] != '-') {
>> > - ctx->opt = arg + 1;
>> > + ctx->opt = ++arg;
>> >if (internal_help && *ctx->opt == 'h')
>> >return usage_with_options_internal(usagestr,
>> > options, 0);
>> >switch (parse_short_opt(ctx, options)) {
>> >case -1:
>> > - return parse_options_usage(usagestr, options,
>> > arg + 1, 1);
>> > + return parse_options_usage(usagestr, options,
>> > arg, 1);
>> >case -2:
>> >goto unknown;
>> > + case -3:
>> > + goto exclusive;
>>
>> BTW, it may be a time to define return error codes.
>
> Yeah, this thing looks unnecessarily complicated :-\
OK, will do it as a separate patch later.
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/
[PATCH] soc: qcom: scm: Clarify boot interface
The secure world only knows about 32-bit wide physical addresses
for the boot API. Clarify the kernel interface by explicitly
stating a u32 instead of phys_addr_t which could be 32 or 64 bits
depending on LPAE or not.
Signed-off-by: Stephen Boyd
---
drivers/soc/qcom/scm-boot.c | 2 +-
include/soc/qcom/scm-boot.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/qcom/scm-boot.c b/drivers/soc/qcom/scm-boot.c
index 3e4d77b371c6..af16fcc8d5cb 100644
--- a/drivers/soc/qcom/scm-boot.c
+++ b/drivers/soc/qcom/scm-boot.c
@@ -24,7 +24,7 @@
/*
* Set the cold/warm boot address for one of the CPU cores.
*/
-int scm_set_boot_addr(phys_addr_t addr, int flags)
+int scm_set_boot_addr(u32 addr, int flags)
{
struct {
__le32 flags;
diff --git a/include/soc/qcom/scm-boot.h b/include/soc/qcom/scm-boot.h
index 02b445c426ce..3e210fb818bb 100644
--- a/include/soc/qcom/scm-boot.h
+++ b/include/soc/qcom/scm-boot.h
@@ -21,6 +21,6 @@
#define SCM_FLAG_WARMBOOT_CPU2 0x10
#define SCM_FLAG_WARMBOOT_CPU3 0x40
-int scm_set_boot_addr(phys_addr_t addr, int flags);
+int scm_set_boot_addr(u32 addr, int flags);
#endif
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1 v3] driver:mtd:spi-nor: Add Micron quad I/O support
This patch adds code which enables Quad I/O mode on Micron SPI NOR flashes.
For Micron SPI NOR flash, enabling or disabling quad I/O protocol is controlled
by EVCR (Enhanced Volatile Configuration Register), Quad I/O protocol bit 7.
When EVCR bit 7 is reset to 0, the SPI NOR flash will operate in quad I/O mode.
Signed-off-by: bean huo
Acked-by: Marek Vasut
---
v1-v2:modified to that capture wait_till_ready()
return value,if error,directly return its
the value.
v2-v3:directly use the reurning error value of
read_reg and write_reg,instead of -EINVAL.
drivers/mtd/spi-nor/spi-nor.c | 46 +
include/linux/mtd/spi-nor.h |6 ++
2 files changed, 52 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index b5ad6be..486b167 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -878,6 +878,45 @@ static int spansion_quad_enable(struct spi_nor *nor)
return 0;
}
+static int micron_quad_enable(struct spi_nor *nor) {
+ int ret, val;
+
+ ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, , 1);
+ if (ret < 0) {
+ dev_err(nor->dev, "error %d reading EVCR\n", ret);
+ return ret;
+ }
+
+ write_enable(nor);
+
+ /* set EVCR ,enable quad I/O */
+ nor->cmd_buf[0] = val & ~EVCR_QUAD_EN_MICRON;
+ ret = nor->write_reg(nor, SPINOR_OP_WD_EVCR, nor->cmd_buf, 1, 0);
+ if (ret < 0) {
+ dev_err(nor->dev,
+ "error while writing EVCR register\n");
+ return ret;
+ }
+
+ ret = wait_till_ready(nor);
+ if (ret)
+ return ret;
+
+ /* read EVCR and check it */
+ ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, , 1);
+ if (ret < 0) {
+ dev_err(nor->dev, "error %d reading EVCR\n", ret);
+ return ret;
+ }
+ if (val & EVCR_QUAD_EN_MICRON) {
+ dev_err(nor->dev, "Micron EVCR Quad bit not clear\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int set_quad_mode(struct spi_nor *nor, u32 jedec_id) {
int status;
@@ -890,6 +929,13 @@ static int set_quad_mode(struct spi_nor *nor, u32 jedec_id)
return -EINVAL;
}
return status;
+ case CFI_MFR_ST:
+ status = micron_quad_enable(nor);
+ if (status) {
+ dev_err(nor->dev, "Micron quad-read not enabled\n");
+ return -EINVAL;
+ }
+ return status;
default:
status = spansion_quad_enable(nor);
if (status) {
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h index
9e6294f..d71b659 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -56,6 +56,10 @@
/* Used for Spansion flashes only. */
#define SPINOR_OP_BRWR 0x17/* Bank register write */
+/* Used for Micron flashes only. */
+#define SPINOR_OP_RD_EVCR 0x65/* Read EVCR register */
+#define SPINOR_OP_WD_EVCR 0x61/* Write EVCR register */
+
/* Status Register bits. */
#define SR_WIP 1 /* Write in progress */
#define SR_WEL 2 /* Write enable latch */
@@ -67,6 +71,8 @@
#define SR_QUAD_EN_MX 0x40/* Macronix Quad I/O */
+#define EVCR_QUAD_EN_MICRON0x80/* Micron Quad I/O */
+
/* Flag Status Register bits */
#define FSR_READY 0x80
--
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: hung tasks in 3.18.0-rc1-00221-gc3351df
On Thu, Oct 23, 2014 at 04:21:17PM +0300, Meelis Roos wrote: > This is first real test on a computer where 3.17 did hang. Fist the hung > task info, then full dmesg. > > [ 960.346611] INFO: task kworker/u16:0:6 blocked for more than 120 seconds. > [ 960.346616] Tainted: GW 3.18.0-rc1-00221-gc3351df #150 > [ 960.346618] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [ 960.346621] kworker/u16:0 D 0 6 2 > 0x > [ 960.346633] Workqueue: netns cleanup_net > [ 960.346635] 880111c4d1e0 0002 880111c4d1e0 > 880111c53fd8 > [ 960.346639] 880111c4d1e0 a000 880111c4d1e0 > 0296 > [ 960.346642] 7fff 7fff > 8182e010 > [ 960.346646] Call Trace: > [ 960.346654] [] ? schedule_timeout+0x18d/0x200 > [ 960.346660] [] ? get_state_synchronize_rcu+0x10/0x10 > [ 960.346664] [] ? wait_for_completion+0xb4/0x110 > [ 960.346669] [] ? _raw_spin_unlock_irqrestore+0x5/0x10 > [ 960.346672] [] ? wait_for_completion+0xa9/0x110 > [ 960.346677] [] ? wake_up_state+0x10/0x10 > [ 960.346681] [] ? _rcu_barrier+0x14a/0x1d0 > [ 960.346686] [] ? netdev_run_todo+0x5c/0x310 > [ 960.346691] [] ? rollback_registered_many+0x265/0x2d0 > [ 960.346696] [] ? default_device_exit_batch+0x136/0x150 > [ 960.346701] [] ? __wake_up_sync+0x10/0x10 > [ 960.346704] [] ? cleanup_net+0xf0/0x1d0 > [ 960.346709] [] ? process_one_work+0x136/0x380 > [ 960.346713] [] ? pwq_activate_delayed_work+0x27/0x40 > [ 960.346716] [] ? worker_thread+0x63/0x480 > [ 960.346720] [] ? rescuer_thread+0x270/0x270 > [ 960.346723] [] ? kthread+0xce/0xf0 > [ 960.346726] [] ? queue_kthread_work+0x80/0x80 > [ 960.346729] [] ? kthread_create_on_node+0x180/0x180 > [ 960.346734] [] ? ret_from_fork+0x7c/0xb0 > [ 960.346737] [] ? kthread_create_on_node+0x180/0x180 > [ 1080.363583] INFO: task kworker/u16:0:6 blocked for more than 120 seconds. > [ 1080.363589] Tainted: GW 3.18.0-rc1-00221-gc3351df #150 > [ 1080.363591] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [ 1080.363594] kworker/u16:0 D 0 6 2 > 0x > [ 1080.363604] Workqueue: netns cleanup_net > [ 1080.363607] 880111c4d1e0 0002 880111c4d1e0 > 880111c53fd8 > [ 1080.363610] 880111c4d1e0 a000 880111c4d1e0 > 0296 > [ 1080.363614] 7fff 7fff > 8182e010 > [ 1080.363617] Call Trace: > [ 1080.363625] [] ? schedule_timeout+0x18d/0x200 > [ 1080.363633] [] ? get_state_synchronize_rcu+0x10/0x10 > [ 1080.363637] [] ? wait_for_completion+0xb4/0x110 > [ 1080.363641] [] ? _raw_spin_unlock_irqrestore+0x5/0x10 > [ 1080.363645] [] ? wait_for_completion+0xa9/0x110 > [ 1080.363649] [] ? wake_up_state+0x10/0x10 > [ 1080.363653] [] ? _rcu_barrier+0x14a/0x1d0 > [ 1080.363658] [] ? netdev_run_todo+0x5c/0x310 > [ 1080.363663] [] ? rollback_registered_many+0x265/0x2d0 > [ 1080.363667] [] ? default_device_exit_batch+0x136/0x150 > [ 1080.363672] [] ? __wake_up_sync+0x10/0x10 > [ 1080.363676] [] ? cleanup_net+0xf0/0x1d0 > [ 1080.363681] [] ? process_one_work+0x136/0x380 > [ 1080.363684] [] ? pwq_activate_delayed_work+0x27/0x40 > [ 1080.363688] [] ? worker_thread+0x63/0x480 > [ 1080.363691] [] ? rescuer_thread+0x270/0x270 > [ 1080.363695] [] ? kthread+0xce/0xf0 > [ 1080.363698] [] ? queue_kthread_work+0x80/0x80 > [ 1080.363702] [] ? kthread_create_on_node+0x180/0x180 > [ 1080.363706] [] ? ret_from_fork+0x7c/0xb0 > [ 1080.363709] [] ? kthread_create_on_node+0x180/0x180 The get_state_synchronize_rcu() from within the wait for _rcu_barrier() looks a bit odd, but perhaps this is stack-tracing inaccuracy. Could you please send your .config? Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] tracing, function_graph: fix micro seconds notation in comment
Hi Byungchul,
On Thu, 23 Oct 2014 17:17:21 +0900, byungchul park wrote:
> From: Byungchul Park
>
> Usually, "msecs" notation means milli-seconds, and "usecs" notation
> means micro-seconds. Since the unit used in the code is
> micro-seconds, the notation should be replaced from msecs to usecs.
> This confusing notation prevents us from understanding the code
> correctly.
>
> Signed-off-by: Byungchul Park
> ---
> kernel/trace/trace_functions_graph.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/trace/trace_functions_graph.c
> b/kernel/trace/trace_functions_graph.c
> index f0a0c98..c18a1e3 100644
> --- a/kernel/trace/trace_functions_graph.c
> +++ b/kernel/trace/trace_functions_graph.c
> @@ -822,10 +822,10 @@ print_graph_duration(unsigned long long duration,
> struct trace_seq *s,
>
> /* Signal a overhead of time execution to the output */
> if (flags & TRACE_GRAPH_PRINT_OVERHEAD) {
> - /* Duration exceeded 100 msecs */
> + /* Duration exceeded 100 usecs */
> if (duration > 10ULL)
> ret = trace_seq_puts(s, "! ");
> - /* Duration exceeded 10 msecs */
> + /* Duration exceeded 10 usecs */
> else if (duration > 1ULL)
I thought the duration was in usec, but it seems not, it's in nsec, hmm.
Then this exceeding 10/100 usec is not meaningful - what about increaing
numbers in the conditional so that it can match to the comment? That
will eliminate the need of the patch 2.
Also I think msecs_str in trace_print_graph_duration() should be renamed
to usecs_str.
Thanks,
Namhyung
> ret = trace_seq_puts(s, "+ ");
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/3] fpga bridge framework
On Thu, 23 Oct 2014, at...@opensource.altera.com wrote: > From: Alan Tull > > Followup to bridge framework that was posted on 2013/10/3 > > This is a driver for enabling/disabling the fpga bridges under control > of a sys entry. It has a common framework and individual drivers for > the various bridges. > > This framework uses the reset driver where appropriate. > > Alan > Forgot to mention: This patchset needs Dinh Nguyen's "reset: add reset_control_status helper function" patches https://lkml.org/lkml/2014/10/10/256 Alan > > Alan Tull (3): > add sysfs document for fpga bridges > ARM: dts: socfpga: fpga bridges bindings docs > fpga bridge driver > > Documentation/ABI/testing/sysfs-class-fpga-bridge |5 + > .../bindings/fpga/altera-fpga2sdram-bridge.txt | 57 + > .../bindings/fpga/altera-hps2fpga-bridge.txt | 53 + > drivers/misc/Kconfig |3 +- > drivers/misc/Makefile |1 + > drivers/misc/fpga-bridge/Kconfig | 20 ++ > drivers/misc/fpga-bridge/Makefile |6 + > drivers/misc/fpga-bridge/altera-fpga2sdram.c | 236 > > drivers/misc/fpga-bridge/altera-hps2fpga.c | 220 ++ > drivers/misc/fpga-bridge/fpga-bridge.c | 230 +++ > drivers/misc/fpga-bridge/fpga-bridge.h | 51 + > 11 files changed, 881 insertions(+), 1 deletion(-) > create mode 100644 Documentation/ABI/testing/sysfs-class-fpga-bridge > create mode 100644 > Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt > create mode 100644 > Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt > create mode 100644 drivers/misc/fpga-bridge/Kconfig > create mode 100644 drivers/misc/fpga-bridge/Makefile > create mode 100644 drivers/misc/fpga-bridge/altera-fpga2sdram.c > create mode 100644 drivers/misc/fpga-bridge/altera-hps2fpga.c > create mode 100644 drivers/misc/fpga-bridge/fpga-bridge.c > create mode 100644 drivers/misc/fpga-bridge/fpga-bridge.h > > -- > 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 v2 1/3] add sysfs document for fpga bridges
From: Alan Tull Add sysfs document for fpga bridges. Signed-off-by: Alan Tull --- Documentation/ABI/testing/sysfs-class-fpga-bridge |5 + 1 file changed, 5 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-fpga-bridge diff --git a/Documentation/ABI/testing/sysfs-class-fpga-bridge b/Documentation/ABI/testing/sysfs-class-fpga-bridge new file mode 100644 index 000..b3303ae --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-fpga-bridge @@ -0,0 +1,5 @@ +What: /sys/class/fpga-bridge//enable +Date: October 2014 +KernelVersion: 3.18 +Contact: Alan Tull +Description: Enable bridge. Write 1 to bring bridge out of reset. -- 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 v2 2/3] ARM: dts: socfpga: fpga bridges bindings docs
From: Alan Tull
Add DTS binding documentation for the Altera FPGA bridges.
Signed-off-by: Alan Tull
---
.../bindings/fpga/altera-fpga2sdram-bridge.txt | 57
.../bindings/fpga/altera-hps2fpga-bridge.txt | 53 ++
2 files changed, 110 insertions(+)
create mode 100644
Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
create mode 100644
Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
diff --git
a/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
new file mode 100644
index 000..cc8f522
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
@@ -0,0 +1,57 @@
+Altera FPGA To SDRAM Bridge Driver
+
+This driver manages a bridge between an FPGA and the SDRAM used by an host
+processor system (HPS). The bridge contains a number read ports, write ports,
+and command ports. Reconfiguring these ports requires that no SDRAM
+transactions occur during reconfiguration. In other words, the code
+reconfiguring the ports cannot be run out of SDRAM nor can the FPGA access the
+SDRAM during the reconfiguration. This driver does not support reconfiguring
+the ports. Typcially, the ports are configured by code running out of onchip
+ram before Linux is started.
+
+This driver supports enabling and disabling of the configured ports all at
+once, which allows for safe reprogramming of the FPGA from user space, provided
+the new FPGA image uses the same port configuration. User space can enable or
+disable the bridge by writing a "1" or a "0", respectively, to its enable file
+under bridge's entry in /sys/class/fpga-bridge. Typically, one disables the
+bridges before reprogramming the FPGA. Once the FPGA is reprogrammed, the
+bridges are reenabled.
+
+Required properties:
+
+ - compatible : "altr,socfpga-fpga2sdram-bridge"
+
+ - read-ports-mask : Bits 0 to 3 corresponds read ports 0 to 3. A bit set to 1
+ indicates the corresponding read port should be enabled.
+
+ - write-ports-mask : Bits 0 to 3 corresponds write ports 0 to 3. A bit set
+ to 1 indicates the corresponding write port should be
+ enabled.
+
+ - cmd-ports-mask : Bits 0 to 5 correspond to command ports 0 to 5. A bit set
+ to 1 indicates the corresponding command port should be
+ enabled.
+
+ - altr,sdr-syscon : phandle of the sdr module
+
+Optional properties:
+
+ - label: name that you want this bridge to show up as under
+ /sys/class/fpga-bridge. Default is br if this is
+ not specified.
+
+ - init-val : 0 if driver should disable bridge at startup
+ 1 if driver should enable bridge at startup
+ driver leaves bridge in current state if property not
+ specified.
+
+Example:
+ fpga2sdram_br: fpgabridge@3 {
+ compatible = "altr,socfpga-fpga2sdram-bridge";
+ label = "fpga2sdram";
+ altr,sdr-syscon = <>;
+ read-ports-mask = <3>;
+ write-ports-mask = <3>;
+ cmd-ports-mask = <0xd>;
+ init-val = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
new file mode 100644
index 000..bc24a2e
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
@@ -0,0 +1,53 @@
+Altera FPGA/HPS Bridge Driver
+
+This driver manages a bridge between a FPGA and a host processor system (HPS).
+User space can enable or disable the bridge by writing a "1" or a "0",
+respectively, to its enable file under bridge's entry in
+/sys/class/fpga-bridge. Typically, one disables the bridges before
+reprogramming the FPGA. Once the FPGA is reprogrammed, the bridges are
+reenabled.
+
+Required properties:
+
+ - compatible : should contain one of:
+ "altr,socfpga-hps2fpga-bridge"
+ "altr,socfpga-lwhps2fpga-bridge"
+ "altr,socfpga-fpga2hps-bridge"
+
+ - clocks : clocks used by this module
+
+ - altr,l3-syscon : phandle of the l3 interconnect module
+
+Optional properties:
+ - label : name that you want this bridge to show up as under
+/sys/class/fpga-bridge. Default is br if this is
+not specified.
+
+ - init-val : 0 if driver should disable bridge at startup
+1 if driver should enable bridge at startup
+driver leaves bridge in current state if property not
+specified.
+
+Example:
+ hps_fpgabridge0: fpgabridge@0 {
+ compatible = "altr,socfpga-hps2fpga-bridge";
+ label = "hps2fpga";
+
