>On Fri, Apr 19, 2013 at 09:52:42PM +0800, rogera...@realtek.com wrote:
>> From: Roger Tseng
>>
>> Adding support of model RTL8411B. Since the model is similar to RTL8411,
>> differences are implemented in rtl8411.c.
>>
>
>What tree is this against?
>
>regards,
>dan carpenter
It should be the
Hi
On Fri, Apr 19, 2013 at 7:24 PM, Greg KH wrote:
> On Fri, Apr 19, 2013 at 06:33:54PM -0700, Anatol Pomozov wrote:
>> Follow-up for https://lkml.org/lkml/2013/4/12/391
>>
>> * make warning smp-safe
>> * result of atomic _unless_zero functions should be checked by caller
>> to avoid
All regulators have ascendant voltage list in this driver.
Thus use regulator_map_voltage_ascend is more efficient than the default
regulator_map_voltage_iterate.
Signed-off-by: Axel Lin
---
drivers/regulator/tps6586x-regulator.c |1 +
1 file changed, 1 insertion(+)
diff --git
On 2013年04月19日 20:13, Arnd Bergmann wrote:
> On Friday 19 April 2013, Chen Gang wrote:
>> > when compiling with allmodconfig, CONFIG_64BIT=y
>> > the file drivers/base/regmap/regmap-mmio.c will use readq and writeq.
>> >
>> > so we need implement these functions.
>> >
>> > BTW:
>> >
All regulators have ascendant voltage list in this driver.
Some regulators have more than 200 supported voltages.
e.g.
For TPS65910_REG_VDD1 and TPS65910_REG_VDD2:
n_voltages = VDD1_2_NUM_VOLT_FINE * VDD1_2_NUM_VOLT_COARSE
= 73 * 3
= 219
Thus it worth converting to
On 2013年04月19日 20:12, Arnd Bergmann wrote:
> On Friday 19 April 2013, Chen Gang wrote:
>> in arch/arm64/include/asm, not define the function cmpxchg64
>>
>> when compiling with allmodconfig,
>> drivers/block/blockconsole.c will need this function.
>>
>> I am not quite familiar with ARM64
On Fri, Apr 19, 2013 at 06:33:54PM -0700, Anatol Pomozov wrote:
> Follow-up for https://lkml.org/lkml/2013/4/12/391
>
> * make warning smp-safe
> * result of atomic _unless_zero functions should be checked by caller
> to avoid use-after-free error
>
> Signed-off-by: Anatol Pomozov
> ---
>
On 2013年04月19日 20:15, Arnd Bergmann wrote:
> On Friday 19 April 2013, Chen Gang wrote:
>> > when compiling with allmodconfig.
>> > early_console is already defined as an extern global pointer.
>> >
>> > need let it point to the object which we intend to (like ARM32 done).
>> >
>> >
>> >
On 2013年04月19日 20:31, Catalin Marinas wrote:
> On Fri, Apr 19, 2013 at 11:53:07AM +0100, Chen Gang wrote:
>> when compiling with allmodconfig.
>> early_console is already defined as an extern global pointer.
>>
>> need let it point to the object which we intend to (like ARM32 done).
>>
>>
On 2013年04月19日 20:35, Catalin Marinas wrote:
> On Fri, Apr 19, 2013 at 12:24:37PM +0100, Chen Gang wrote:
>> >
>> > when compiling with allmodconfig, CONFIG_64BIT=y
>> > the file drivers/base/regmap/regmap-mmio.c will use readq and writeq.
>> >
>> > so we need implement these functions.
Follow-up for https://lkml.org/lkml/2013/4/12/391
* make warning smp-safe
* result of atomic _unless_zero functions should be checked by caller
to avoid use-after-free error
Signed-off-by: Anatol Pomozov
---
include/linux/kref.h | 9 ++---
lib/kobject.c| 3 ++-
2 files changed,
On 2013/4/20 4:58, Tejun Heo wrote:
> Hello,
>
> On Fri, Apr 19, 2013 at 08:29:24PM +0800, Li Zefan wrote:
>> +static void update_tasks_cpumask_hier(struct cpuset *root_cs,
>> + bool update_root, struct ptr_heap *heap)
>> +{
>> +struct cpuset *cp;
>> +
On 2013/4/20 2:36, Tejun Heo wrote:
> Hello, Li.
>
> On Fri, Apr 19, 2013 at 08:27:05PM +0800, Li Zefan wrote:
>> I think this was introduced unintentionally when cpuset hotplug was
>> made asynchronous. Fortunately it does no harm, as updating tasks'
>> cpumask will just return failure and
On Thursday, April 18, 2013 01:15:27 PM Stephan von Krawczynski wrote:
> On Wed, 17 Apr 2013 20:55:04 +0200
> "Rafael J. Wysocki" wrote:
>
> > On Wednesday, April 17, 2013 11:38:30 AM Bjorn Helgaas wrote:
> > > [+cc Rafael & linux-acpi]
> >
> > Thanks.
> >
> > > On Tue, Apr 16, 2013 at 10:14
Register with the ARM sched_clock framework now that it supports
64 bits. This also fixes two problems with the current sched_clock
support for machines using the archited timers. First off, we
don't subtract the start value from subsequent sched_clock calls
so we can potentially start off with
The arm architected system counter has at least 56 bits of
useable bits. Add support to ARM's sched_clock implementation for
counters with more than 32 bits so we can avoid the complexity of
dealing with wraparound on these devices while benefiting from
the irqtime accounting and suspend/resume
If we're suspended and sched_clock() is called we're going to
read the hardware one more time and throw away that value and
return back the cached value we saved during the suspend
callback. This is wasteful, let's short circuit all that and
return the cached value if we're suspended as early as
This is what I was thinking. I don't see why we can't move this to generic code
and have arm64 use it too. Those patches will follow once I find an arm64
compiler.
First two patches should probably go in even if the 64 bit stuff doesn't go in
at the same time.
Stephen Boyd (4):
ARM:
The needs_suspend member is unused now that we always do the
suspend/resume handling (see 6a4dae5 (ARM: 7565/1: sched: stop
sched_clock() during suspend, 2012-10-23)).
Signed-off-by: Stephen Boyd
---
arch/arm/kernel/sched_clock.c | 1 -
1 file changed, 1 deletion(-)
diff --git
On 04/19/2013 07:21 PM, Nishanth Menon wrote:
> On 14:55-20130419, Taras Kondratiuk wrote:
>> Using a "voltage tolerance" for doing DVFS is not a proper way.
>> It leads to a few issues:
>> - voltage is limited to a narrow range near OPP voltage,
>> so other
Commit-ID: 74c3e3fcf350b2e7e3eaf9550528ee3f74e44b37
Gitweb: http://git.kernel.org/tip/74c3e3fcf350b2e7e3eaf9550528ee3f74e44b37
Author: H. Peter Anvin
AuthorDate: Fri, 19 Apr 2013 16:36:03 -0700
Committer: H. Peter Anvin
CommitDate: Fri, 19 Apr 2013 16:36:03 -0700
x86, microcode:
On 04/19/2013 10:38 AM, Matt Fleming wrote:
>
> Richard Weinberger (2):
> x86,efi: Check max_size only if it is non-zero.
> x86,efi: Implement efi_no_storage_paranoia parameter
>
OK, I'll pull this for now, but this *really* need to be an automatic
quirk of some sort, especially
On Tue, Mar 26, 2013 at 04:28:27PM +0100, Olaf Hering wrote:
> This change fixes a few compile errors:
>
> hv_vss_daemon.c:64:15: warning: unknown escape sequence '\/'
> hv_vss_daemon.c:64:15: warning: unknown escape sequence '\/'
> hv_vss_daemon.c: In function 'vss_operate':
>
Moves the relocation handling into C, after decompression. Only
kernels that need relocation support will use the code. The new
CONFIG_RANDOMIZE_BASE does not yet do anything except turn on this logic
for 64-bit kernels.
Based on work by Neill Clift and Michael Davidson.
Signed-off-by: Kees Cook
On 04/19/2013 02:44 PM, Bryan O'Donoghue wrote:
> On 19/04/13 22:25, Borislav Petkov wrote:
>> On Fri, Apr 19, 2013 at 10:55:15PM +0200, Borislav Petkov wrote:
>>> Just filter out P5 and earlier. The code already does that for CPUs
>>> which don't have CPUID.
>>
>> Actually, an alternative - more
On Saturday 20 April 2013, Jon Hunter wrote:
> Change also means that of_dma_request_slave_channel() cannot be called
> from a context where it is not possible to sleep too, right? May be
> worth mentioning this in the changelog as well.
You already cannot do that, because it requires
On Fri, Apr 19, 2013 at 8:43 AM, Michel Lespinasse wrote:
>
> Just a suggestion: when file->f_op->mmap returns an error code,
> mmap_region() currently has to call unmap_region() to undo any partial
> mappings that might have been created by the device driver. Would it
> make more sense to ask
On Fri, Apr 19, 2013 at 3:55 PM, Sedat Dilek wrote:
>
> Davidlohr pointed to this patch (tested the triplet):
>
> ipc, sem: do not call sem_lock when bogus sma:
> https://lkml.org/lkml/2013/3/31/12
>
> Is that what you mean?
Yup.
Linus
--
To unsubscribe from this list: send the line
On Sat, Apr 20, 2013 at 12:50 AM, Linus Torvalds
wrote:
> On Fri, Apr 19, 2013 at 3:34 PM, Sedat Dilek wrote:
>>
>> See attached dmesg.
>
> This still has the bug Davidlohr pointed at:
>
>>> This looks like what Emmanuel was/is running into:
>>> https://lkml.org/lkml/2013/3/30/1
>
> you need to
On Wed, Apr 17, 2013 at 10:51:23AM +0200, Nicolas Ferre wrote:
> On 04/17/2013 10:39 AM, Fabio Porcedda :
> > On Thu, Mar 21, 2013 at 12:40 PM, Nicolas Ferre
> > wrote:
> >> These patches clean up at91_cf a bit and add DT bindings.
> >> It is based on a previous series from Joachim Eastwood and
On Fri, Apr 19, 2013 at 3:34 PM, Sedat Dilek wrote:
>
> See attached dmesg.
This still has the bug Davidlohr pointed at:
>> This looks like what Emmanuel was/is running into:
>> https://lkml.org/lkml/2013/3/30/1
you need to move the "IS_ERR()" check before the sem_lock.
Linus
--
On 04/19/2013 04:42 AM, Lars-Peter Clausen wrote:
> Currently the OF DMA code uses a spin lock to protect the of_dma_list from
> concurrent access and a per controller reference count to protect the
> controller
> from being freed while a request operation is in progress. If
>
On 04/19/2013 10:38 AM, Matt Fleming wrote:
> Hi guys,
>
> There's a few bug fixes sitting in the EFI urgent branch. Please
> consider pulling.
>
We are *post -rc7* and days away from release.
I can't push this to Linus without a detailed description of what this
is and why we need it now.
On 04/19/2013 05:10 AM, Arnd Bergmann wrote:
> On Friday 19 April 2013, Lars-Peter Clausen wrote:
>> of_dma_request_slave_channel() currently does not drop the reference to the
>> dma_spec of_node if no DMA controller matching the of_node could be found.
>> This
>> patch fixes it by always
On 04/20/2013 06:05 AM, Alexey Khoroshilov wrote:
> If ext4_fill_super() failed after extents status shrinker
> has been registered, the shrinker is left in a global list
> while the memory, it sits in, is already freed.
> Oops is not so bad scenario after that.
>
> Found by Linux File System
Hi Rob,
On 19.04.2013 [14:23:21 -0500], Rob Herring wrote:
> On 04/19/2013 02:01 PM, Nishanth Aravamudan wrote:
> > Running 3.9-rc7-ish, tripped the following (also being seen in FC19
> > alpha) on ppc64:
> >
> > [ 117.026196] =
> > [
If ext4_fill_super() failed after extents status shrinker
has been registered, the shrinker is left in a global list
while the memory, it sits in, is already freed.
Oops is not so bad scenario after that.
Found by Linux File System Verification project (linuxtesting.org).
Signed-off-by: Alexey
On 04/19/2013 02:44 PM, Bryan O'Donoghue wrote:
> On 19/04/13 22:25, Borislav Petkov wrote:
>> On Fri, Apr 19, 2013 at 10:55:15PM +0200, Borislav Petkov wrote:
>>> Just filter out P5 and earlier. The code already does that for CPUs
>>> which don't have CPUID.
>>
>> Actually, an alternative - more
1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- linux-next-20130419.orig/fs/ceph/file.c
> +++ linux-next-20130419/fs/ceph/file.c
> @@ -748,7 +748,7 @@ retry_snap:
> goto out;
> }
>
> - dout("aio_write %p %llx.%llx %llu~%ld getting caps.
On Fri, Apr 19, 2013 at 2:31 PM, Samuel Ortiz wrote:
> Hi Andrey,
>
> On Thu, Apr 18, 2013 at 09:58:26AM -0700, Andrey Smirnov wrote:
>> Driver for Si476x series of chips
>>
>> This is a eight version of the patchset originaly posted here:
>> https://lkml.org/lkml/2012/9/13/590
>>
>> Second
On Fri, Apr 19, 2013 at 02:01:49PM -0700, Kevin Hilman wrote:
> "Paul E. McKenney" writes:
>
> > +KNOWN ISSUES
>
> [...]
>
> > +o Unless all CPUs are idle, at least one CPU must keep the
> > + scheduling-clock interrupt going in order to support accurate
> > + timekeeping.
>
> At least
* Steven Rostedt (rost...@goodmis.org) wrote:
> On Mon, 2013-04-15 at 11:13 +0900, kpark3...@gmail.com wrote:
> > From: Sahara
> >
> > Somehow tracepoint_entry_add_probe function allows a null probe function.
> > And, this may lead to unexpected result since the number of probe
> > functions in
On 19/04/13 22:25, Borislav Petkov wrote:
On Fri, Apr 19, 2013 at 10:55:15PM +0200, Borislav Petkov wrote:
Just filter out P5 and earlier. The code already does that for CPUs
which don't have CPUID.
Actually, an alternative - more practical albeit not very accurate
More practical ? Hmm -
On Fri, Apr 19, 2013 at 02:24:10PM -0700, Linus Torvalds wrote:
> On Fri, Apr 19, 2013 at 2:09 PM, Sedat Dilek wrote:
> >
> > I have applied all three patches and see still call-traces.
> > New are apparmor related messages.
>
> Can you try the crazy rcu double-free debug hack?
>
> See
>
>
On Mon, 2013-04-15 at 11:13 +0900, kpark3...@gmail.com wrote:
> From: Sahara
>
> Somehow tracepoint_entry_add_probe function allows a null probe function.
> And, this may lead to unexpected result since the number of probe
> functions in an entry can be counted by checking whether probe is null
On Fri, Apr 19, 2013 at 08:55:24PM +0200, Peter Zijlstra wrote:
> On Fri, 2013-04-19 at 09:41 -0500, Jacob Shin wrote:
> >
> > Thank you again, for taking the time.
>
> Ah something I just remembered, could you do a patch like the below
> one? That makes things like perf stat -A work as
Hi Andrey,
On Thu, Apr 18, 2013 at 09:58:26AM -0700, Andrey Smirnov wrote:
> Driver for Si476x series of chips
>
> This is a eight version of the patchset originaly posted here:
> https://lkml.org/lkml/2012/9/13/590
>
> Second version of the patch was posted here:
>
On Thu, 2013-04-18 at 18:34 +0200, Vincent Guittot wrote:
> The current update of the rq's load can be erroneous when RT tasks are
> involved
>
> The update of the load of a rq that becomes idle, is done only if the avg_idle
> is less than sysctl_sched_migration_cost. If RT tasks and short idle
On Fri, Apr 19, 2013 at 10:55:15PM +0200, Borislav Petkov wrote:
> Just filter out P5 and earlier. The code already does that for CPUs
> which don't have CPUID.
Actually, an alternative - more practical albeit not very accurate
solution would be to check for which families Intel delivers
On Fri, Apr 19, 2013 at 2:09 PM, Sedat Dilek wrote:
>
> I have applied all three patches and see still call-traces.
> New are apparmor related messages.
Can you try the crazy rcu double-free debug hack?
See
https://lkml.org/lkml/2013/3/30/113
and I'm re-attaching the ugly-ass crazy hack
It does.
The bug appears with fairly-sized read transactions (in the order of kB)
returning corrupted data.
Josef
> Josef.
>
> This fixes a real bug for us does it not, some failure case with a
> sustained amount of traffic ?
>
>
> Bryan
>
>
--
To unsubscribe from this list: send the line
', but argument 11 has type 'ssize_t' [-Wformat]
Signed-off-by: Randy Dunlap
Cc: Sage Weil
Cc: ceph-de...@vger.kernel.org
---
fs/ceph/file.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-next-20130419.orig/fs/ceph/file.c
+++ linux-next-20130419/fs/ceph/file.c
...@vger.kernel.org
---
fs/nilfs2/page.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20130419.orig/fs/nilfs2/page.c
+++ linux-next-20130419/fs/nilfs2/page.c
@@ -426,7 +426,7 @@ void nilfs_clear_dirty_page(struct page
lock_buffer(bh
"Paul E. McKenney" writes:
> +KNOWN ISSUES
[...]
> +oUnless all CPUs are idle, at least one CPU must keep the
> + scheduling-clock interrupt going in order to support accurate
> + timekeeping.
At least with the implementation I'm using (Frederic's 3.9-nohz1
branch), at least one
Hello,
On Fri, Apr 19, 2013 at 08:29:24PM +0800, Li Zefan wrote:
> +static void update_tasks_cpumask_hier(struct cpuset *root_cs,
> + bool update_root, struct ptr_heap *heap)
> +{
> + struct cpuset *cp;
> + struct cgroup *pos_cgrp;
> +
> + if
> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Friday, April 19, 2013 4:50 PM
> To: Haiyang Zhang
> Cc: net...@vger.kernel.org; KY Srinivasan; o...@aepfle.de;
> jasow...@redhat.com; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org
> Subject:
On Fri, Apr 19, 2013 at 09:35:18PM +0100, Bryan O'Donoghue wrote:
> Just returning X86_VENDOR_UNKNOWN - won't fix the bug though - after
> all MSR_IA32_UCODE_REV is also x86_family() >= 6
What are you talking about?
If you return X86_VENDOR_UNKNOWN from x86_vendor(),
load_ucode_intel_bsp() and
On Thu, Apr 18, 2013 at 02:38:53PM +0400, Vasiliy Tolstov wrote:
> Hello. I'm using linux 3.8.6 and mdadm 3.2.6 (from git).
> I have many raid1 arrays that have data offset 2048 (metadata 1.2,
> created with various mdadm versions but mostly 3.2.1 on linux 2.6.32).
> If i create raid1 with never
From: Haiyang Zhang
Date: Tue, 16 Apr 2013 15:25:50 -0700
> Fixed: warning: cast from pointer to integer of different size
>
> The Hyper-V hosts always use 64 bit request id. The guests can have 32 or 64
> bit pointers which equal to the ulong type size. So we cast it to ulong type.
> And,
On 19/04/13 20:11, Borislav Petkov wrote:
On Fri, Apr 19, 2013 at 06:23:03PM +0100, Bryan O'Donoghue wrote:
Architectural MSRs associated with microcode are for P6 or higher.
Add a check to early microcode to detect< P6.
Without a check for< P6 - we end up reading from unimplemented MSRs
on
Herbert,
This is a follow on patch to the optimized sha256 and sha512 patch series
that's just
merged into the crypto-dev. Let me know if you prefer me to respin the
patch series.
This patch corrects the prototype of sha256_transform_asm and
sha512_transform_asm function pointer declaration to
On Fri, 2013-04-19 at 15:19 -0400, Rik van Riel wrote:
> On 04/19/2013 02:53 PM, Sedat Dilek wrote:
> > On Fri, Apr 19, 2013 at 6:43 PM, Sedat Dilek wrote:
> >
> >> I tried to switch from SLUB to SLAB...
> >>
> >> ...and also from VIRT_CPU_ACCOUNTING_GEN to TICK_CPU_ACCOUNTING.
> >>
> >> 2x NOPE.
Hi Daniel - this looks good, only one minor comment below...
On Thu, Apr 11, 2013 at 10:56:01AM -0400, Daniel De Graaf wrote:
> This is a complete rewrite of the Xen TPM frontend driver, taking
> advantage of a simplified frontend/backend interface and adding support
> for cancellation and
On Sat, Apr 13, 2013 at 4:54 AM, Heinrich Schuchardt wrote:
> Dear Justin,
>
> looking at the example at
> http://www.lanedo.com/~aleksander/fanotify/fanotify-example.c
> the large file support is enabled by passing O_LARGEFILE to fanotify_init:
>
> if ((fanotify_fd = fanotify_init
On 04/19/2013 02:01 PM, Nishanth Aravamudan wrote:
> Running 3.9-rc7-ish, tripped the following (also being seen in FC19
> alpha) on ppc64:
>
> [ 117.026196] =
> [ 117.026216] [ INFO: possible irq lock inversion dependency detected ]
> [
On 04/19/2013 02:53 PM, Sedat Dilek wrote:
On Fri, Apr 19, 2013 at 6:43 PM, Sedat Dilek wrote:
I tried to switch from SLUB to SLAB...
...and also from VIRT_CPU_ACCOUNTING_GEN to TICK_CPU_ACCOUNTING.
2x NOPE.
In one kernel-build I saw in my console...
semop(1): encountered an error:
On Fri, Apr 19, 2013 at 09:38:04AM +0800, Wang YanQing wrote:
> The linux/iommu.h header uses ERR_PTR defined
> in linux/err.h but doesn't include it.
>
> Cc:j...@8bytes.org
> Reviewed-by: Alex Williamson
> Signed-off-by: Wang YanQing
Applied to core branch, thanks.
--
To unsubscribe from
On Fri, Apr 19, 2013 at 06:23:03PM +0100, Bryan O'Donoghue wrote:
> Architectural MSRs associated with microcode are for P6 or higher.
> Add a check to early microcode to detect < P6.
>
> Without a check for < P6 - we end up reading from unimplemented MSRs
> on Pentium.
Is this something you're
These inlines are only used by kernel/sched/fair.c so they do not
need to be present in the main kernel/sched/sched.h file.
Cc: Ingo Molnar
Cc: Peter Zijlstra
Signed-off-by: Paul Gortmaker
---
kernel/sched/fair.c | 18 ++
kernel/sched/sched.h | 18 --
2 files
This large chunk of load calculation code can be easily divorced from
the main core.c scheduler file, with only a couple prototypes and
externs added to a kernel/sched header.
Some recent commits expanded the code and the documentation of it,
making it large enough to warrant separation. For
Recent activity has had a focus on moving functionally related blocks of
stuff out of sched/core.c into stand-alone files. The code relating to load
calculations has grown significantly enough recently to warrant placing it in
a separate file.
Here we do that, and in doing so, we shed ~20k of
From: Bill Nottingham
This enum leaks out to userspace via error messages, so fix the spelling.
Signed-off-by: Bill Nottingham
Signed-off-by: Tomas Winkler
---
V2: rebased
drivers/misc/mei/hbm.c | 8
drivers/misc/mei/hw-me.c | 2 +-
drivers/misc/mei/init.c| 4 ++--
From a969728248c3b439dc97a69e7dac133b5efa34e7 Mon Sep 17 00:00:00 2001
From: Josef Ahmad
Date: Fri, 19 Apr 2013 17:28:10 +0100
Subject: [PATCH] i2c-designware: fix RX FIFO overrun
i2c_dw_xfer_msg() pushes a number of bytes to transmit/receive
to/from the bus into the TX FIFO.
For master-rx
1. Rename the function and change parameters order,
so that first parameter is mei_device
2. Simplify the function code flow
3. Rename helper functions to more self descriptive names
4. Use helpers common functions where possible
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/interrupt.c |
While writting to device is limitted to max_msg_length advertized
in client properites the read can be much longer delivered consequiting chunks.
We use krealloc to enlarge the buffer when needed.
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/bus.c | 8
Running 3.9-rc7-ish, tripped the following (also being seen in FC19
alpha) on ppc64:
[ 117.026196] =
[ 117.026216] [ INFO: possible irq lock inversion dependency detected ]
[ 117.026238] 3.9.0-rc7+ #8 Not tainted
[ 117.026251]
The following RCU splat indicates lack of RCU protection:
[ 953.267649] ===
[ 953.267652] [ INFO: suspicious RCU usage. ]
[ 953.267657] 3.9.0-0.rc6.git2.4.fc19.ppc64p7 #1 Not tainted
[ 953.267661] ---
[ 953.267664]
>
> On Fri, Apr 19, 2013 at 09:16:54PM +0300, Tomas Winkler wrote:
> > While writting to device is limitted to max_msg_length advertized in
> > client properites the read can be much longer delivered consequiting
> chunks.
> >
> > We use krealloc to enlarge the buffer when needed.
> >
> >
On Fri, 2013-04-19 at 09:41 -0500, Jacob Shin wrote:
>
> Thank you again, for taking the time.
Ah something I just remembered, could you do a patch like the below
one? That makes things like perf stat -A work as expected.
---
commit 314d9f63f385096580e9e2a06eaa0745d92fe4ac
Author: Yan, Zheng
nts welcome!
>>>>>
>>>>> The panic handlers in our modeset code are pretty decent fubar - they
>>>>> take mutexes all over the place. So I think the backtrace you see
>>>>> there is actually a secondary effect. I've looked into fixing this up,
&g
Hi Nicolas,
On Thu, Apr 18, 2013 at 04:51:42PM +0200, Nicolas Ferre wrote:
> Arnd, Olof,
>
> Third pull-request for AT91 SoC support based on material that you already
> have
> in your arm-soc/at91/soc branch.
> Not very core changes here but interesting enhancements.
>
> Thanks, best regards,
With a kernel tree that contains a generated include/linux/version.h, if
someone just does a git pull to update to a newer kernel version that
includes
commit 10b63956fce7f369cc37fd4d994f09bd5203efe4
"UAPI: Plumb the UAPI Kbuilds into the user header installation and
checking"
and
commit
On 04/19/13 17:33, Joe Perches wrote:
> Reduce object space ~2% using more current logging styles.
>
> Neaten and simplify logging macros.
> Use wiphy_ where appropriate.
> Coalesce formats.
>
> Convert ERROR/WARNING/INFO macros to rt2x00_
> Convert EEPROM to rt2x00_eeprom_dbg
> Convert
Hello, Li.
On Fri, Apr 19, 2013 at 08:27:05PM +0800, Li Zefan wrote:
> I think this was introduced unintentionally when cpuset hotplug was
> made asynchronous. Fortunately it does no harm, as updating tasks'
> cpumask will just return failure and there's a guarantee_online_mems()
> when updating
On Fri, Apr 19, 2013 at 09:13:54AM +, EUNBONG SONG wrote:
>
>
> On Fri, Apr 19, 2013 at 12:01:04AM +, EUNBONG SONG wrote:
> >>
> >> I think HZ/50 is better than 2 for adapter timeout.
>
> > Basically OK. But why HZ/50? Most drivers use HZ.
>
> Actually, I just translated 2 jiffies
On Thu, Apr 18, 2013 at 07:40:16AM +, 송은봉 wrote:
>
> I rewrite my patch because the patch before i sent have many white space.
> Thanks!
This should have been below the "---" after the sigend-off.
> ---
> I've been debugging the abnormal operation of i2c on octeon.
> If a process is
On Fri, 2013-04-19 at 12:55 -0400, Jörn Engel wrote:
> On Fri, 19 April 2013 10:59:35 -0700, Joe Perches wrote:
> > }
> > list_add(>list, _device_list);
> > - INFO("mtd%d: [%s] erase_size = %dKiB [%d]", dev->mtd.index,
> > - dev->mtd.name + strlen("block2mtd: "),
> > -
On Fri, Apr 19, 2013 at 08:26:15PM +0800, Li Zefan wrote:
> The test is done in set_cpus_allowed_ptr(), so it's redundant.
>
> Signed-off-by: Li Zefan
For 0001-0004,
Acked-by: Tejun Heo
I'll apply these into for-3.11 once v3.10-rc1 drops.
Thanks.
--
tejun
--
To unsubscribe from this
On Fri, Apr 19, 2013 at 09:16:54PM +0300, Tomas Winkler wrote:
> While writting to device is limitted to max_msg_length advertized
> in client properites the read can be much longer delivered consequiting
> chunks.
>
> We use krealloc to enlarge the buffer when needed.
>
> Signed-off-by: Tomas
Is this easy to reproduce? Do you know whether the same thing happens
> with an upstream kernel, e.g., v3.8 or v3.9-rc7? If it turns out that
> this bug still exists in the upstream kernel, Zhang will probably be
> interested in it.
It isn't easy to simulate. It only happened to me one. I'll file
Same comment as before, I'd like to see this using the generic IIO to HWMON
bridge instead of recreating it.
On 04/19/2013 06:56 PM, Anthony Olech wrote:
> This patch is relative to next-20130419 of linux-next
>
> This is the HWMON component driver of the Dialog DA9058 PMIC.
>
On Fri, 19 April 2013 10:59:35 -0700, Joe Perches wrote:
> }
> list_add(>list, _device_list);
> - INFO("mtd%d: [%s] erase_size = %dKiB [%d]", dev->mtd.index,
> - dev->mtd.name + strlen("block2mtd: "),
> - dev->mtd.erasesize >> 10,
>
> Why do you ack a patch that doesn't apply? :)
Sorry for that didn't check it much ...it was just spelling which others are
obviously better in than me.
Anyhow I took a liberty to rebase it myself
Thanks
Tomas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Same issues as in v5 plus one more ...
On 04/19/2013 06:56 PM, Anthony Olech wrote:
> This patch is relative to next-20130419 of linux-next
>
> This is the ADC component driver of the Dialog DA9058 PMIC.
> This driver is just one component of the whole DA9058 PMIC
> dri
While writting to device is limitted to max_msg_length advertized
in client properites the read can be much longer delivered consequiting chunks.
We use krealloc to enlarge the buffer when needed.
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/bus.c | 8
From: Bill Nottingham
This enum leaks out to userspace via error messages, so fix the spelling.
Signed-off-by: Bill Nottingham
Signed-off-by: Tomas Winkler
---
V2: rebased
drivers/misc/mei/hbm.c | 8
drivers/misc/mei/hw-me.c | 2 +-
drivers/misc/mei/init.c| 4 ++--
Rename the function to mei_amthif_irq_read_msg
and change parameters order
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/amthif.c| 10 +-
drivers/misc/mei/interrupt.c | 2 +-
drivers/misc/mei/mei_dev.h | 9 +
3 files changed, 15 insertions(+), 6 deletions(-)
diff
Hey,
On Fri, Apr 19, 2013 at 06:10:57AM +0800, Lai Jiangshan wrote:
> Ping.
Sorry, I've been at collab summit / lsf. Plus, it's a bit too late
for for-3.10 anyway. Anyways, after glancing over it, here are my
preliminary thoughts. The first one looks good but I'm not sure about
dropping
On Fri, Apr 19, 2013 at 10:38 AM, KOSAKI Motohiro
wrote:
>> I feel we are hitting the same issue than this patch:
>> https://lkml.org/lkml/2013/4/5/116
>>
>> I'm adding Kosaki in Cc, who proposed roughly the same fix.
>
> Thanks to CCing. I'm now sitting LSF and I can't read whole tons emails.
>
introduced in kernel 3.9 CONFIG_ARM_VIRT_EXT is default for all V7 arm
cpu's. this is wrong and breaks smp support on BCM4708 for example.
so keep it optional since no all v7 cpu's seem to support it. BCM4708
for instance is a arm cortex-a9. please merge this into one of the next
patches.
1 - 100 of 904 matches
Mail list logo
