On Fri, 2013-11-15 at 17:53 -0200, Geyslan Gregório Bem wrote:
Hi,
> Hi guys,
>
> In the function msgin_qtag() [line 2632], this dereference was intentional?
>
> static struct ScsiReqBlk *msgin_qtag(struct AdapterCtlBlk *acb,
> struct DeviceCtlBlk *dcb, u8 tag)
> {
> struct
CONGRATULATIONS! YOU HAVE BEEN AWARDED 1 MILLION POUNDS FROM QATAR
FOUNDATION XMAS PROMOTION..CONTACT FOR MORE
information.qaterfoundationxmaspr...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
CONGRATULATIONS! YOU HAVE BEEN AWARDED 1 MILLION POUNDS FROM QATAR
FOUNDATION XMAS PROMOTION..CONTACT FOR MORE
information.qaterfoundationxmaspr...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
add cc Seth 's new email address.
On Fri, Nov 8, 2013 at 6:28 PM, Bob Liu wrote:
> On 11/08/2013 05:50 PM, changkun.li wrote:
>> In zswap, store page A to zbud if the compression ratio is high, insert
>> its entry into rbtree. if there is a entry B which has the same offset
>> in the
>> This is generic test module (samples/hw_breakpoint/data_breakpoint.ko)
>> which places watchpoint for bothe read/write.
>> Atleast watchpt should have triggered for Read right? I also tried
>> with othe functions like do_fork, vfs_read etc but no hit.
>
> You'd need to place something for exec
On 15.11.2013 16:52, Steven Rostedt wrote:
> So let me get this straight. The recording of the cdma_push() data is
> slow, correct? What mapping are you talking about?
>
> trace_host1x_cdma_push(dev_name(cdma_to_channel(cdma)->dev),
> op1, op2);
>
>
On 15 November 2013 22:07, Will Deacon wrote:
>> well, kprobes does not step from kernel address, but it prepares a
>> allocated memory(executable), copies the instruction and update the
>> single step address (ELR) to enable stepping while ERET.
>> So, don't we need NOP at next location after
This message is from Naukri Job Portal and to all registered Naukri account
owners. We are currently facing phishers on our Data Base due to Spam. We want
to exercise an improve secure service quality in our Admin System to reduce the
spam in every job/users portal. Please Confirm your Naukri
On Fri, Mar 22, 2013 at 3:23 AM, Thomas Gleixner wrote:
> --- linux-2.6.orig/kernel/cpu/idle.c
> +++ linux-2.6/kernel/cpu/idle.c
> +void cpu_startup_entry(enum cpuhp_state state)
> +{
> + current_set_polling();
> + arch_cpu_idle_prepare();
> + cpu_idle_loop();
> +}
> +#endif
On 五, 2013-11-15 at 09:07 +0100, Jean Delvare wrote:
> Hi Eduardo,
>
> On Tue, 12 Nov 2013 15:46:04 -0400, Eduardo Valentin wrote:
> > This patch introduces a device tree bindings for
> > describing the hardware thermal behavior and limits.
> > Also a parser to read and interpret the data and
On 15 November 2013 22:12, Will Deacon wrote:
> On Thu, Nov 14, 2013 at 11:04:04AM +, Sandeepa Prabhu wrote:
>> Hi Jean,
>>
>> I have applied this patchset on aarch64 upstream branch,cross-compiled
>> for arm64 and try running some tests for hardware breakpoints.
>>
>> I cross-compiled perf
Hi Oleg,
Sorry for my late response!
On 11/16/2013 01:12 AM, Oleg Nesterov wrote:
> On 11/15, Oleg Nesterov wrote:
>>
>> But probably list_last_entry() makes sense in the "else" branch,
>> athough this is minor.
>>
>>
>> Off-topic. Not sure this really makes sense, but I was thinking about
>>
If --show-task option is given, also print internal COMM, FORK and
EXIT events. It would be helpful for debugging.
$ perf script --show-task
...
swapper 0 [009] 3350640.335261: sched:sched_switch:
prev_comm=swapper/9
sleep 9486 [009] 3350640.335509: comm: perf -->
The print_sample_start() will be reused by other printing routine for
internal events like COMM, FORK and EXIT from next patch. And because
they're not tied to a specific event, move the evname print code to
its caller.
Reviewed-by: David Ahern
Signed-off-by: Namhyung Kim
---
If --show-mmap option is given, also print internal MMAP and MMAP2
events. It would be helpful for debugging.
$ perf script --show-mmap
...
sleep 9486 [009] 3350640.335531: mmap: [(0x40 - 0x406000) @ 0
]: x /usr/bin/sleep
sleep 9486 [009] 3350640.335542: mmap:
Hi David,
On Sun, 17 Nov 2013 21:47:59 -0700, David Ahern wrote:
> On 11/17/13, 8:00 PM, Namhyung Kim wrote:
>> If --show-mmap option is given, also print internal MMAP and MMAP2
>> events. It would be helpful for debugging.
>>
>> Suggested-by: Frederic Weisbecker
>> Signed-off-by: Namhyung Kim
On 11/17/13, 8:00 PM, Namhyung Kim wrote:
If --show-mmap option is given, also print internal MMAP and MMAP2
events. It would be helpful for debugging.
Suggested-by: Frederic Weisbecker
Signed-off-by: Namhyung Kim
Outside of the free following a strdup, the 3 patches looked good to me.
On Sun, Nov 17, 2013 at 12:29:37PM +0900, Tejun Heo wrote:
> On Sat, Nov 16, 2013 at 10:21:19PM -0500, Dave Jones wrote:
> > On Sun, Nov 17, 2013 at 11:17:36AM +0900, Tejun Heo wrote:
> >
> >
> > > +if (has_mmap)
> > > +mutex_init(>mutex);
> > > +else
> > > +
On 11/17/13, 8:00 PM, Namhyung Kim wrote:
@@ -578,6 +579,106 @@ static int process_attr(struct perf_tool *tool, union
perf_event *event,
return perf_evsel__check_attr(evsel, scr->session);
}
+static int process_comm_event(struct perf_tool *tool,
+ union
From: Namhyung Kim
The uprobe syntax requires an offset after a file path not a symbol.
Reviewed-by: Masami Hiramatsu
Cc: Srikar Dronamraju
Cc: Oleg Nesterov
Cc: zhangwei(Jovi)
Cc: Arnaldo Carvalho de Melo
Signed-off-by: Namhyung Kim
---
Documentation/trace/uprobetracer.txt | 10
From: Namhyung Kim
The print format of s32 type was "ld" and it's casted to "long". So
it turned out to print 4294967295 for "-1" on 64-bit systems. Not
sure whether it worked well on 32-bit systems.
Anyway, it'd be better if we have exact format and type cast for each
types on both of 32-
On Mon, Nov 18, 2013 at 11:07:12AM +0800, Peng Tao wrote:
> On Sun, Nov 17, 2013 at 3:59 AM, Greg Kroah-Hartman
> wrote:
> > On Sat, Nov 16, 2013 at 10:36:18AM +, Dilger, Andreas wrote:
> >> >So, sorry, I have to stop here at this series. I've applied the first 3
> >> >to the opw-next branch
On Sun, Nov 17, 2013 at 11:50 PM, Geyslan G. Bem wrote:
> Put the 'pdata->card_int_gpio' assignment in inner scope, avoiding
> explicit null dereference.
>
> Signed-off-by: Geyslan G. Bem
> ---
> drivers/mmc/host/sdhci-spear.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Acked-by:
On 11/18/2013 12:14 PM, Chen Gang wrote:
> For all uapi headers, need use "_UAPI" prefix for its guard macro
> (which will be stripped by "scripts/headers_installer.sh").
>
> Also be sure that all standard header files have their guard macros,
> and remove all files which only "asm-generic"
For all uapi headers, need use "_UAPI" prefix for its guard macro
(which will be stripped by "scripts/headers_installer.sh").
Also be sure that all standard header files have their guard macros,
and remove all files which only "asm-generic" related (add 'generic-by'
in "Kbuild").
Also be sure
Hi MyungJoo,
On 18 November 2013 08:07, MyungJoo Ham wrote:
>
> 2013. 11. 15. 오후 8:44에 "Sachin Kamat" 님이 작성:
>
>
>>
>> Original cover letter from Yadwinder:
>> This series is to add basic common infrastructure for ASV.
>> Basically ASV is a technique used on samsung SoCs, which provides the
>>
On Sun, Nov 17, 2013 at 06:15:32PM -0800, Joe Perches wrote:
> On Sun, 2013-11-17 at 21:07 -0500, Greg Price wrote:
> > Perhaps the following tweak to the error message would make this
> > subtlety clearer?
>
> Maybe, but this case isn't a macro. It's a function.
> Dunno if differentiating when
On Sun, Nov 17, 2013 at 07:28:40PM +0100, Pavel Machek wrote:
> Hi!
>
> > On Mon, Nov 11, 2013 at 11:19:41PM +0100, Pavel Machek wrote:
> > > > + if (of_get_property(np, "linux,input-no-autorepeat", NULL))
> > > > + keypad_data->no_autorepeat = true;
> > >
> > > From 2/2:
> >
On 11/17/2013 07:35 PM, Chen Gang wrote:
> For all uapi headers, need use "_UAPI" prefix for its guard macro
> (which will be stripped by "scripts/headers_installer.sh").
>
> Also be sure that all standard header files have their guard macros.
>
I removed all files which only includes related
Hi all,
Please do *not* add any v3.14 material to linux-next until after
v3.13-rc1 is released.
Changes since 20131115:
Linus' tree gained 2 build failures for which I reverted a commit and
applied a merge fix patch.
The nfs tree gained a build failure for which I reverted a commit.
The i2c
Hello All,
On 12 November 2013 12:05, Naveen Krishna Chatradhi
wrote:
> This patchset does a little clean up of the existing code
> 1. [v9] thermal: samsung: replace inten_ bit fields with intclr_
> 2. [v9] thermal: samsung: change base_common to more meaningful base_second
>
> adds support
To: Shawn Guo
On 11/13/2013 08:13 PM, Jean Delvare wrote:
> On Wed, 13 Nov 2013 19:02:26 +0800, Wei Ni wrote:
>> Previous versions are:
>> [v5]: http://patchwork.ozlabs.org/patch/281017/
>> [v4]: http://lkml.indiana.edu/hypermail/linux/kernel/1309.1/02812.html
>>
>> On 11/13/2013 06:59 PM, Wei
Hello All,
On 12 November 2013 12:06, Naveen Krishna Chatradhi
wrote:
> This patch replaces the inten_rise_shift/mask and inten_fall_shift/mask
> with intclr_rise_shift/mask and intclr_fall_shift/mask respectively.
> Currently, inten_rise_shift/mask and inten_fall_shift/mask bits are only used
>
Hello All,
On 12 November 2013 12:06, Naveen Krishna Chatradhi
wrote:
> On Exynos5440 and Exynos5420 there are registers common
> across the TMU channels.
>
> To support that, we introduced a ADDRESS_MULTIPLE flag in the
> driver and the 2nd set of register base and size are provided
> in the
Hello All,
On 12 November 2013 12:07, Naveen Krishna Chatradhi
wrote:
> Exynos5420 has 5 TMU channels, the TRIMINFO register is
> misplaced for TMU channels 2, 3 and 4
> TRIMINFO at 0x1006c000 contains data for TMU channel 3
> TRIMINFO at 0x100a contains data for TMU channel 4
> TRIMINFO at
Hello All,
On 12 November 2013 12:07, Naveen Krishna Chatradhi
wrote:
> Exynos5420 SoC has per core thermal management unit.
> 5 TMU channels 4 for CPUs and 5th for GPU.
>
> This patch adds the device tree nodes to the DT device list.
>
> Nodes carry the misplaced second base address and the
Hi all,
After merging the final tree, today's linux-next build (sparc64 defconfig)
failed like this:
arch/sparc/mm/init_64.c: In function 'pte_alloc_one':
arch/sparc/mm/init_64.c:2568:9: error: unused variable 'pte'
[-Werror=unused-variable]
Caused by the merge between commit 37b3a8ff3e08
On Sun, Nov 17, 2013 at 3:59 AM, Greg Kroah-Hartman
wrote:
> On Sat, Nov 16, 2013 at 10:36:18AM +, Dilger, Andreas wrote:
>> >So, sorry, I have to stop here at this series. I've applied the first 3
>> >to the opw-next branch of staging.git so they can live somewhere until
>> >3.13-rc1 is
On 11/18/2013 12:59 AM, Catalin Marinas wrote:
On 17 November 2013 08:49, Alexandre Courbot wrote:
The ARM tree includes a firmware_ops interface that is designed to
implement support for simple, TrustZone-based firmwares but could
also cover other use-cases. It has been suggested that this
On Sat, 2013-11-16 at 17:03 +0100, Oleg Nesterov wrote:
> On 11/15, Andrew Morton wrote:
> >
> > Enable autofs4 to work in a "container". oz_pgrp is converted from pid_t
> > to struct pid and this is stored at mount time based on the "pgrp=" option
> > or if the option is missing then the current
Hi Geert,
On Sat, 16 Nov 2013 21:43:32 +0100 Geert Uytterhoeven
wrote:
>
> On Thu, Nov 7, 2013 at 3:14 PM, Kirill A. Shutemov
> wrote:
> > --- a/include/linux/mm.h
> > +++ b/include/linux/mm.h
>
> > +static inline void pgtable_init(void)
> > +{
> > + ptlock_cache_init();
> > +
If --show-task option is given, also print internal COMM, FORK and
EXIT events. It would be helpful for debugging.
Suggested-by: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/perf/Documentation/perf-script.txt | 3 +
tools/perf/builtin-script.c | 110
Hi all,
After merging the final tree, today's linux-next build (sparc64 defconfig)
failed like this:
In file included from arch/sparc/include/asm/tlbflush_64.h:4:0,
from arch/sparc/include/asm/tlbflush.h:4,
from arch/sparc/include/asm/pgtable_64.h:961,
If --show-mmap option is given, also print internal MMAP and MMAP2
events. It would be helpful for debugging.
Suggested-by: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/perf/Documentation/perf-script.txt | 3 ++
tools/perf/builtin-script.c | 78
The print_sample_start() will be reused by other printing routine for
internal events like COMM, FORK and EXIT from next patch. And because
they're not tied to a specific event, move the evname print code to
its caller.
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-script.c | 11
On Sun, Nov 17, 2013 at 3:50 AM, Greg Kroah-Hartman
wrote:
> On Sat, Nov 16, 2013 at 11:20:37AM +, Dilger, Andreas wrote:
>> On 2013/11/14 9:13 PM, "Greg Kroah-Hartman"
>> wrote:
>>
>> >On Fri, Nov 15, 2013 at 12:13:07AM +0800, Peng Tao wrote:
>> >> From: "John L. Hammond"
>> >>
>> >> Add a
On Sun, Nov 17, 2013 at 06:15:32PM -0800, Joe Perches wrote:
> > > sparse matches gcc behaviour (I hope), but it warns about such abuses.
> > > It's a defect, all right - one being reported by sparse.
> >
> > Perhaps the following tweak to the error message would make this
> > subtlety clearer?
>
On Mon, Nov 18, 2013 at 12:15 AM, Joe Perches wrote:
> On Sun, 2013-11-17 at 21:07 -0500, Greg Price wrote:
>
> Maybe, but this case isn't a macro. It's a function.
> Dunno if differentiating when it's a macro or a
> function is difficult though.
>
>
The case which was initially reported by
From: Namhyung Kim
After processing all group descriptors or encountering an error, it
frees all descriptors. However, current logic can leak memory since
it might not traverse all descriptors.
Note that the 'i' can have different value than nr_groups when an
error occurred and it's safe to
From: Namhyung Kim
When processing event group descriptor in perf file header, we reuse
an allocated group name but forgot to prevent it from freeing.
Reported-by: Stephane Eranian
Signed-off-by: Namhyung Kim
---
tools/perf/util/header.c | 4 +++-
1 file changed, 3 insertions(+), 1
Hi all,
After merging the final tree, today's linux-next build (powerpc
ppc44x_defconfig) failed like this:
fs/nfs/dir.c: In function 'nfs_readdir_xdr_to_array':
fs/nfs/dir.c:593:2: error: implicit declaration of function 'nfs4_label_alloc'
[-Werror=implicit-function-declaration]
On Fri, 15 Nov 2013, Tejun Heo wrote:
> Hello,
>
> Shawn, Hugh, can you please verify whether the attached patch makes
> the deadlock go away?
Thanks a lot, Tejun: report below.
>
> Thanks.
>
> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> index e0839bc..dc9dc06 100644
> ---
> > > +/*
> > > + * These are default attributes that are added for every memmap entry.
> > > + */
> > > +static struct attribute *def_attrs[] = {
> > > + _type_attr.attr,
> > > + _phys_addr_attr.attr,
> > > + _virt_addr_attr.attr,
> > > + _num_pages_attr.attr,
> > > + _attribute_attr.attr,
> > >
On Sun, 2013-11-17 at 21:07 -0500, Greg Price wrote:
> [+linux-sparse and Chris]
>
> On Mon, Nov 18, 2013 at 01:33:49AM +, Al Viro wrote:
> > On Sun, Nov 17, 2013 at 02:45:05PM -0800, Joe Perches wrote:
> > > Yes. I think it's a defect in how sparse
> > > treats string concatenation.
> > >
On 11/15/13 at 04:02pm, Toshi Kani wrote:
> On Tue, 2013-11-05 at 16:20 +0800, dyo...@redhat.com wrote:
> > Kexec kernel will use saved runtime virtual mapping, so add a
> > new function efi_remap_region to remapping it directly without
> > calculate the virt addr from efi_va.
> >
> > The md is
On 11/15/13 at 04:21pm, Toshi Kani wrote:
> On Tue, 2013-11-05 at 16:20 +0800, dyo...@redhat.com wrote:
> > Add two small functions:
> > efi_merge_regions and efi_map_regions, efi_enter_virtual_mode
> > calls them instead of embedding two long for loop.
>
> :
>
> > +void __init
Hello Linus,
Please pull battery-2.6 git tree to receive changes prepared for the v3.13
release. Highlights:
- A new driver for TI BQ24735 Battery Chargers, courtesy of NVidia.
- Device tree bindings for TWL4030 chips.
- Random fixes and cleanups.
Thank you,
Anton
The following changes
[+linux-sparse and Chris]
On Mon, Nov 18, 2013 at 01:33:49AM +, Al Viro wrote:
> On Sun, Nov 17, 2013 at 02:45:05PM -0800, Joe Perches wrote:
> > Yes. I think it's a defect in how sparse
> > treats string concatenation.
> >
> > That style [... with printk ...] is pretty common in the kernel
On Tue, Nov 12, 2013 at 08:22:18AM -0500, Mark Salter wrote:
> Signed-off-by: Mark Salter
> CC: Richard Kuo
> CC: linux-hexa...@vger.kernel.org
> ---
> arch/hexagon/include/asm/fixmap.h | 40
> +--
> 1 file changed, 1 insertion(+), 39 deletions(-)
>
Thanks
On Sun, 2013-11-17 at 20:15 -0500, John David Anglin wrote:
> On 17-Nov-13, at 7:52 PM, James Bottomley wrote:
>
> >> +void flush_user_dcache_page(struct page *page);
> >> +
> >
> > The split into flush_kernel.. and flush_user.. is pointless. We
> > have no
> > use for a flush_user_.. API
On Sun, Nov 17, 2013 at 5:19 PM, 韩磊 wrote:
> when we delete,add,search,amend the list_head,should we use spinlock
> or rcu in case of conflicit to list_head???
There is no implicit locking when we use 'list' api's.You should explicitly
do that AFAIK.
>
> Thank you!
> --
> To unsubscribe from this
Hi Kim,
> -Original Message-
> From: Jaegeuk Kim [mailto:jaegeuk@samsung.com]
> Sent: Monday, November 18, 2013 8:29 AM
> To: Chao Yu
> Cc: linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net; 谭姝
> Subject: Re: [f2fs-dev] [PATCH V2
On Sun, Nov 17, 2013 at 02:45:05PM -0800, Joe Perches wrote:
> On Sun, 2013-11-17 at 20:34 -0200, Erico Nunes wrote:
> > Do you mean it as an error in the sparse tool?
>
> Yes. I think it's a defect in how sparse
> treats string concatenation.
>
> That style:
>
> printk("%s\n",
> #ifdef
when we delete,add,search,amend the list_head,should we use spinlock
or rcu in case of conflicit to list_head???
Thank you!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On 17-Nov-13, at 7:52 PM, James Bottomley wrote:
+void flush_user_dcache_page(struct page *page);
+
The split into flush_kernel.. and flush_user.. is pointless. We
have no
use for a flush_user_.. API because it's not part of the standard
linux
one. Plus it's going to confuse those who
2013/11/17 James Bottomley :
> On Sun, 2013-11-17 at 19:09 -0200, Geyslan Gregório Bem wrote:
>> 2013/11/17 James Bottomley :
>> > On Sun, 2013-11-17 at 15:51 -0300, Geyslan G. Bem wrote:
>> >> This patch fix memory leakage in cases 'ISCSI_NET_PARAM_VLAN_ID' and
>> >>
On 17-Nov-13, at 6:47 PM, Helge Deller wrote:
I only changed kunmap_parisc() to always call
flush_kernel_dcache_page_addr(addr) - independend if we are on a
PA8800/8900
CPU or not - which is what you proposed in your original mail.
In which case the flushes in clear_user_page() and
Hi List,
I am getting this in kernel 3.11 x86_64
Nov 17 18:56:19 joker4 kernel: [drm:i915_hangcheck_elapsed] *ERROR* stuck on
render ring
Nov 17 18:56:19 joker4 kernel: [drm] capturing error event; look for more
information in /sys/kernel/debug/dri/0/i915_error_state
Nov 17 18:56:19 joker4
On Mon, Nov 18, 2013 at 11:33:25AM +1100, Kevin Easton wrote:
> That's part of an ASCII string, "DEP=2\0SE", so if that looks familiar
> to anyone (part of a kernel command line?) it might give a clue to
> where the timer callback pointer is being overwritten.
Yeah, it could be anything, maybe
Diploma?
http://tiny.cc/2e91ozwh7m
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Mon, 2013-11-18 at 00:47 +0100, Helge Deller wrote:
> * James Bottomley :
> > On Sun, 2013-11-17 at 22:23 +0100, Helge Deller wrote:
> > > On 11/16/2013 09:09 PM, Benjamin LaHaise wrote:
> > > > On Sat, Nov 16, 2013 at 09:07:18PM +0100, Simon Baatz wrote:
> > > >> On Fri, Nov 15, 2013 at
-- Forwarded message --
From: 韩磊
Date: 2013/11/16
Subject: About deadline IO scheduler in kernel
To: Linux Kernel Mailing List
In deadline scheduler, in a FIFO list when a request insert it and
other request remove it in the same time,whether it make conflict???
Whether it
On Sun, Nov 17, 2013 at 11:06:12PM +0100, Borislav Petkov wrote:
> and the virtual address in rIP is 8106f5c3, i.e. the same one
> as in the photo. Thus, the CALL instruction tries to call the timer
> function 'fn' which we pass as an argument to call_timer_fn.
>
> However, the address
Hi Chao,
2013-11-16 (토), 14:14 +0800, Chao Yu:
> For better read performance, we add a new function to support for merging
> contiguous read as the one for write.
Please consider 80 columns for the description.
I cannot fix this at every time though. :(
>
> v1-->v2:
> o add declarations here
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-edac.git
linux_next
For:
- sb_edac: add support for Ivy Bridge support;
- cell_edac: add a missing of_node_put() call
-
Following up the last week's discussion about EDAC, here's my part
* James Bottomley :
> On Sun, 2013-11-17 at 22:23 +0100, Helge Deller wrote:
> > On 11/16/2013 09:09 PM, Benjamin LaHaise wrote:
> > > On Sat, Nov 16, 2013 at 09:07:18PM +0100, Simon Baatz wrote:
> > >> On Fri, Nov 15, 2013 at 02:42:05PM -0800, James Bottomley wrote:
> > >>> On Fri, 2013-11-15 at
Hi Wolfram,
After merging the i2c tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/i2c/busses/i2c-bcm-kona.c: In function 'bcm_kona_send_i2c_cmd':
drivers/i2c/busses/i2c-bcm-kona.c:268:2: error: implicit declaration of
function 'INIT_COMPLETION'
On Sun, Nov 17, 2013 at 10:31:07PM +0100, Arend van Spriel wrote:
> Wouldn't it be better to fix it in brcmsmac.
You're right, BCMA_DRIVER_GPIO doesn't need LEDS_CLASS.
So, the only solution I can think of right now is below, maybe
adding a hidden config symbol CONFIG_BRCMSMAC_LEDS which depends
On Sun, Nov 17, 2013 at 11:45 PM, Joe Perches wrote:
> On Sun, 2013-11-17 at 20:34 -0200, Erico Nunes wrote:
>> Do you mean it as an error in the sparse tool?
>
> Yes. I think it's a defect in how sparse
> treats string concatenation.
>
> That style:
>
> printk("%s\n",
> #ifdef FOO
>
On Sun, Nov 17, 2013 at 11:34:20PM +0100, Rafael J. Wysocki wrote:
> This looks like a softirq bug to me (and related to cpuidle).
Reportedly, it happens right after resume from RAM. Francis, is that
correct?
> I'm wondering if that happens with any of the older kernels or just
> 3.12?
That
On Sun, 2013-11-17 at 20:34 -0200, Erico Nunes wrote:
> Do you mean it as an error in the sparse tool?
Yes. I think it's a defect in how sparse
treats string concatenation.
That style:
printk("%s\n",
#ifdef FOO
"foo"
#endif
#ifdef BAR
"bar"
#endif
"string");
is
This patch fixes the following errors reported when running sparse:
fs/jffs2/super.c:378:1: error: directive in argument list
fs/jffs2/super.c:380:1: error: directive in argument list
fs/jffs2/super.c:381:1: error: directive in argument list
fs/jffs2/super.c:383:1: error: directive in argument
Thanks for your reply.
I'll resubmit shortly.
Do you mean it as an error in the sparse tool?
I don't think so, I took a look and it seems to be designed to output
an error for that case.
On Sun, Nov 17, 2013 at 7:40 PM, Joe Perches wrote:
> On Sun, 2013-11-17 at 18:18 -0200, Erico Nunes
On Sunday, November 17, 2013 11:06:12 PM Borislav Petkov wrote:
> On Sun, Nov 17, 2013 at 09:49:40PM +0100, Francis Moreau wrote:
> > On Sun, Nov 17, 2013 at 8:53 PM, Borislav Petkov wrote:
> > > On Sun, Nov 17, 2013 at 07:02:21PM +0100, Francis Moreau wrote:
> > >> Sorry I haven't taken the
On Sat, 16 Nov 2013 19:50:37 +0200, Pantelis Antoniou
wrote:
> Hi Grant,
>
> On Nov 15, 2013, at 7:46 PM, Grant Likely wrote:
>
> > Adds a few simple test cases to ensure that addition, update and removal
> > of device tree node properties works correctly.
> >
> > Signed-off-by: Grant Likely
On Sat, 16 Nov 2013 13:09:13 -0600, Rob Herring wrote:
> On Fri, Nov 15, 2013 at 11:46 AM, Grant Likely
> wrote:
> > Adds a few simple test cases to ensure that addition, update and removal
> > of device tree node properties works correctly.
> >
> > Signed-off-by: Grant Likely
> > Cc: Rob
On Sun, Nov 17, 2013 at 09:49:40PM +0100, Francis Moreau wrote:
> On Sun, Nov 17, 2013 at 8:53 PM, Borislav Petkov wrote:
> > On Sun, Nov 17, 2013 at 07:02:21PM +0100, Francis Moreau wrote:
> >> Sorry I haven't taken the original picture large enough, and getting
> >> this kernel panic is pretty
It looks like this typo was introduced by a mistake in a copy-and-paste in
commit ddbe32491951.
Signed-off-by: Adam Cozzette
---
drivers/hid/usbhid/usbkbd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/usbhid/usbkbd.c b/drivers/hid/usbhid/usbkbd.c
index
On Sun, 2013-11-17 at 22:23 +0100, Helge Deller wrote:
> On 11/16/2013 09:09 PM, Benjamin LaHaise wrote:
> > On Sat, Nov 16, 2013 at 09:07:18PM +0100, Simon Baatz wrote:
> >> On Fri, Nov 15, 2013 at 02:42:05PM -0800, James Bottomley wrote:
> >>> On Fri, 2013-11-15 at 23:05 +0100, Helge Deller
On Sun, 2013-11-17 at 18:18 -0200, Erico Nunes wrote:
> This patch fixes the following errors reported when running sparse:
> fs/jffs2/super.c:378:1: error: directive in argument list
> fs/jffs2/super.c:380:1: error: directive in argument list
> fs/jffs2/super.c:381:1: error: directive in argument
On Sun, 2013-11-17 at 19:09 -0200, Geyslan Gregório Bem wrote:
> 2013/11/17 James Bottomley :
> > On Sun, 2013-11-17 at 15:51 -0300, Geyslan G. Bem wrote:
> >> This patch fix memory leakage in cases 'ISCSI_NET_PARAM_VLAN_ID' and
> >> 'ISCSI_NET_PARAM_VLAN_PRIORITY' and refactors code 'going out'
1 - 100 of 398 matches
Mail list logo
