From: David Jeffery
When checking if an autofs mount point is busy it isn't sufficient to
only check if it's a mount point.
For example, if the mount of an offset mountpoint in a tree is denied
for this host by its export and the dentry becomes a process working
directory the check incorrectly
From: Claudiu Ghioc
Fixed the sparse warning:
* "fs/autofs4/root.c:411:5: warning:
symbol 'autofs4_d_manage' was not declared.
Should it be static?"
edit: imk
Clearly it should be static as the function is declared static at
the top of root.c.
end edit: imk
Signed-off-by: Claudiu
On 05/06/2013 11:34 AM, Michael Wang wrote:
>> > @@ -3045,7 +3045,7 @@ static long effective_load(struct task_group *tg,
>> > int cpu, long wl, long wg)
>> >/*
>> > * w = rw_i + @wl
>> > */
>> > - w = se->my_q->load.weight + wl;
>> > + w =
Hi, Alex
On 05/06/2013 09:45 AM, Alex Shi wrote:
> effective_load calculates the load change as seen from the
> root_task_group. It needs to engage the runnable average
> of changed task.
[snip]
> */
> @@ -3045,7 +3045,7 @@ static long effective_load(struct task_group *tg, int
> cpu, long wl,
On 05/06/2013 11:26 AM, Preeti U Murthy wrote:
> Hi Alex,
>
> You can add my Reviewed-by for the below patch.
>
> Thanks
Thanks a lot for the review!
--
Thanks
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On 05/05/2013 05:27 PM, Alexander Shiyan wrote:
> Signed-off-by: Alexander Shiyan
Applied to my for-curr for 3.10 (to be pushed to Linus is a day or two).
Thx,
-Vineet
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On 05/04/2013 08:52 AM, Marcelo Tosatti wrote:
> On Sat, May 04, 2013 at 12:51:06AM +0800, Xiao Guangrong wrote:
>> On 05/03/2013 11:53 PM, Marcelo Tosatti wrote:
>>> On Fri, May 03, 2013 at 01:52:07PM +0800, Xiao Guangrong wrote:
On 05/03/2013 09:05 AM, Marcelo Tosatti wrote:
>> +
Hi all,
Please do not add any v3.11 destined work to your linux-next included
branches until after v3.10-rc1 is released.
I am receiving a (un)reasonable number of conflicts from there being
multiple copies of some commits in various trees. Please clean this up
and resist the temptataion to
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Seungwon Jeon "
commit c09fbd7451b797213b3df8bf06b9ec33f954 upstream
mci_writew causes a failure of fifo access for 64-bit.
mci_writeq is correct.
Signed-off-by: Seungwon Jeon
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
On 05/05/2013 06:27 AM, Luke Kenneth Casson Leighton wrote:
this message came up on debian-arm and i figured that it is worthwhile
endeavouring to get across to people why device tree cannot and will
not ever be the solution it was believed to be, in the ARM world.
[just a quick note to david
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in ipc/sem.c
between commit 321310ced2d6 ("ipc: move sem_obtain_lock() rcu locking
into the only caller") from Linus' tree and commit "ipc/sem.c:
alternatives to preempt_disable()" from the akpm tree.
I just dropped the akpm
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
On Tue, 2013-04-23 at 20:37 +0800, Hayes Wang wrote:
> File: rtl_nic/rtl8168g-3.fw
> Version: 0.0.1
>
> Signed-off-by: Hayes Wang
> ---
Applied, thanks.
Ben.
> WHENCE| 5 -
> rtl_nic/rtl8168g-3.fw | Bin 0 -> 832 bytes
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
On Tue, 2013-04-23 at 20:37 +0800, Hayes Wang wrote:
> File: rtl_nic/rtl8106e-2.fw
> Version: 0.0.1
>
> Signed-off-by: Hayes Wang
> ---
Applied, thanks.
Ben.
> WHENCE| 3 +++
> rtl_nic/rtl8106e-2.fw | Bin 0 -> 832 bytes
> 2 files changed, 3 insertions(+)
> create mode
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
Hi Alex,
You can add my Reviewed-by for the below patch.
Thanks
Regards
Preeti U Murthy
On 04/04/2013 07:30 AM, Alex Shi wrote:
> In power aware scheduling, we don't want to balance 'prefer_sibling'
> groups just because local group has capacity.
> If the local group has no tasks at the time,
Hi Alex,
You can add my Reviewed-by for the below patch.
Thanks
Regards
Preeti U Murthy
On 04/04/2013 07:30 AM, Alex Shi wrote:
> The cpu's utilization is to measure how busy is the cpu.
> util = cpu_rq(cpu)->avg.runnable_avg_sum * SCHED_POEWR_SCALE
> /
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by:
Hi Alex,
The below patch looks good to me.
On 04/04/2013 07:30 AM, Alex Shi wrote:
> We need initialize the se.avg.{decay_count, load_avg_contrib} for a
> new forked task.
> Otherwise random values of above variables cause mess when do new task
> enqueue:
> enqueue_task_fair
>
On 5/5/13 7:57 PM, Namhyung Kim wrote:
Hi David,
On Fri, 26 Apr 2013 07:44:18 -0600, David Ahern wrote:
On 4/25/13 12:24 AM, Namhyung Kim wrote:
But it looks there's a race between cond_wait() and cond_broatcast().
I'll take a look at that.
Why not use eventfd or a pipe for the signalling
Signed-off-by: Chao Xie
---
.../devicetree/bindings/input/pxa27x-keypad.txt| 60 +
drivers/input/keyboard/pxa27x_keypad.c | 232 +++-
2 files changed, 288 insertions(+), 4 deletions(-)
create mode 100644
The patches include 2 parts
1. use matrix_keypad for matrix keyes support
2. add device tree support for pxa27x-keypad
V2->V1:
Do not copy the members from pdata. For device tree support,
directly allocate the pdata structure.
Chao Xie (5):
input: pxa27x-keypad: use matrix_keymap for matrix
Signed-off-by: Chao Xie
---
arch/arm/mach-mmp/aspenite.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-mmp/aspenite.c b/arch/arm/mach-mmp/aspenite.c
index 9f64d56..1e23346 100644
--- a/arch/arm/mach-mmp/aspenite.c
+++
Signed-off-by: Chao Xie
---
arch/arm/mach-mmp/teton_bga.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-mmp/teton_bga.c b/arch/arm/mach-mmp/teton_bga.c
index 8609967..d8967fa 100644
--- a/arch/arm/mach-mmp/teton_bga.c
+++
Now pxa27x-keypad make use matrix_keymap for matrix keyes, so
remove the unused members in platform data.
Signed-off-by: Chao Xie
---
include/linux/platform_data/keypad-pxa27x.h |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/include/linux/platform_data/keypad-pxa27x.h
pxa27x-keypad includes matrix keyes. Make use of matrix_keymap
for the matrix keyes.
Signed-off-by: Chao Xie
---
drivers/input/keyboard/Kconfig |1 +
drivers/input/keyboard/pxa27x_keypad.c | 36 +-
include/linux/platform_data/keypad-pxa27x.h |
Hi Vasilis,
Sorry for the delay and thank you for reviewing and testing. :)
On 05/03/2013 06:50 PM, Vasilis Liaskovitis wrote:
Should we skip ranges on nodes that the kernel uses? e.g. with
if (memblock_is_kernel_node(nid))
continue;
Yes. I think I forgot to call it
On Fri, 26 Apr 2013 18:18:09 +0200, Jiri Olsa wrote:
> Namhyung,
> if you'd like to check, all changes addressing your comments are in here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
> perf/core_make
>
> I'll wait a bit for other comments and resend the patchset later
Hi David,
On Fri, 26 Apr 2013 07:44:18 -0600, David Ahern wrote:
> On 4/25/13 12:24 AM, Namhyung Kim wrote:
>> But it looks there's a race between cond_wait() and cond_broatcast().
>> I'll take a look at that.
>
> Why not use eventfd or a pipe for the signalling instead?
Thanks for your
On Fri, 26 Apr 2013 10:40:23 +0200, Jiri Olsa wrote:
> On Thu, Apr 25, 2013 at 03:50:45PM +0900, Namhyung Kim wrote:
>> On Wed, 24 Apr 2013 16:17:24 +0200, Jiri Olsa wrote:
>> > On Tue, Apr 23, 2013 at 05:31:10PM +0900, Namhyung Kim wrote:
>> >> From: Namhyung Kim
>> >>
>> >> It's convenient to
They are the base values in load balance, update them with rq runnable
load average, then the load balance will consider runnable load avg
naturally.
Signed-off-by: Alex Shi
---
kernel/sched/core.c | 4 ++--
kernel/sched/fair.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff
We need initialize the se.avg.{decay_count, load_avg_contrib} for a
new forked task.
Otherwise random values of above variables cause mess when do new task
enqueue:
enqueue_task_fair
enqueue_entity
enqueue_entity_load_avg
and make forking balancing imbalance since
effective_load calculates the load change as seen from the
root_task_group. It needs to engage the runnable average
of changed task.
Thanks for Morten Rasmussen and PeterZ's reminder of this.
Signed-off-by: Alex Shi
---
kernel/sched/fair.c | 24
1 file changed, 12
Except using runnable load average in background, move_tasks is also
the key functions in load balance. We need consider the runnable load
average in it in order to the apple to apple load comparison.
Signed-off-by: Alex Shi
---
kernel/sched/fair.c | 8 +++-
1 file changed, 7 insertions(+),
The following variables were covered under CONFIG_SMP in struct cfs_rq.
but similar runnable variables work for UP in struct rq and task_group.
like rq->avg, task_group->load_avg.
So move them out, they also can work with UP.
u64 runnable_load_avg, blocked_load_avg;
atomic64_t
To get the latest runnable info, we need do this cpuload update after
task_tick.
Signed-off-by: Alex Shi
---
kernel/sched/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index ecec7f1..33bcebf 100644
--- a/kernel/sched/core.c
Remove CONFIG_FAIR_GROUP_SCHED that covers the runnable info, then
we can use runnable load variables.
Signed-off-by: Alex Shi
---
include/linux/sched.h | 7 +--
kernel/sched/core.c | 7 +--
kernel/sched/fair.c | 13 ++---
kernel/sched/sched.h | 9 +
4 files
This patchset bases on tip/sched/core.
It fixed a UP config bug. And the last of patch changed, it insert the
runnable load avg into effective_load(), thus the wake_affine consider
load avg via effective_load.
I retested on Intel core2, NHM, SNB, IVB, 2 and 4 sockets machines with
benchmark
Hi Jiri,
Sorry for late reply. I've been busy these days.
On Thu, 25 Apr 2013 15:24:18 +0900, Namhyung Kim wrote:
> On Wed, 24 Apr 2013 16:12:41 +0200, Jiri Olsa wrote:
>> I got following lockup for record command:
>>
>> # ./perf --no-pager ftrace record ls
>> ...
>> hangs
>>
>> in
On 04/29/2013 02:55 AM, Alan Stern wrote:
On Sun, 28 Apr 2013, ZhenHua wrote:
In fact, the patch is so easy that I am including it below. Please
test this (without either of your patches) to see if it works.
Alan Stern
Index: usb-3.9/drivers/usb/host/uhci-hub.c
Old pwm-pxa.c will register driver by arch_initcall. Then other
drivers based on the PWM driver can successully call old
pwm_request because arch_initcall make sure the PWM driver will
be registered earlier.
Now, pwm_request is re-written and done by common layer code. It
will return -EPROBE_DEFER
Add the deice tree support for pwm-pxa.
Signed-off-by: Chao Xie
---
drivers/pwm/pwm-pxa.c | 52 -
1 files changed, 51 insertions(+), 1 deletions(-)
diff --git a/drivers/pwm/pwm-pxa.c b/drivers/pwm/pwm-pxa.c
index aa4bea7..c8d59a2 100644
---
The patches fix some bugs
1. pwm-pxa driver is shared by ARCH_PXA and ARCH_MMP
2. use module_platform_driver for driver register
The patches also add device tree support for pwm.
V2->V1:
Remove the redundant initialization.
Fix bug of no initialization of .of_match_table.
Use CONFIG_OF for
The PWM driver is not only used by ARCH_PXA but also ARCH_MMP.
Signed-off-by: Chao Xie
---
drivers/pwm/Kconfig |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 115b644..9ec4040 100644
--- a/drivers/pwm/Kconfig
+++
On Mon, Apr 08, 2013 at 05:24:22PM +1000, Michael Ellerman wrote:
> On Mon, Mar 04, 2013 at 03:21:05PM +1100, Michael Ellerman wrote:
> > Make it explicit that the format attributes may define overlapping bit
> > ranges. Unfortunately this was left unspecified originally, and all the
> > examples
Hi Ralf,
It looks like John Crispin has cherry-picked or rebased part of Linus'
tree into his branch that you have now merged.
Guys, don't rebase your trees - especially this late and especially after
they have been merged into a published tree.
I will use the mips tree from Friday.
--
Cheers,
Hi Linus,
This is the MFD pull request for the 3.10 merge window. There is one merge
conflict with your tree, and I fixed it for reference in my mfd-3.10-merge
branch.
For 3.10 we have a few new MFD drivers for:
- The ChromeOS embedded controller which provides keyboard, battery and power
>So on 64bits MIPS platforms, __va(__pa(x)) may not equal to x, that may cause
>trouble to free_initmem_default(). Could you please help to do another test
>by changing
>free_initmem_default(POISON_FREE_INITMEM);
>to
>free_initmem_default(0);
>This test could help to identify whether this panic
Hi!
> > NFS calls the freezable helpers with locks held, which is unsafe
> > and caused lockdep warnings when 6aa9707 "lockdep: check that no
> > locks held at freeze time" was applied (reverted in dbf520a).
> > Add new *_unsafe versions of the helpers that will not run the
> > lockdep test when
The umul_ppmm() macro for parisc uses the xmpyu assembler statement
which does calculation via a floating point register.
But usage of floating point registers inside the Linux kernel are not
allowed and gcc will stop compilation due to the -mdisable-fpregs
compiler option.
Fix this by disabling
Module signing functionality breaks the kernel build on parisc with the
following error:
kernel/built-in.o: In function `load_module_signing_keys':
kernel/modsign_pubkey.c:67: undefined reference to
`modsign_certificate_list_end'
kernel/modsign_pubkey.c:66: undefined reference to
On Sun, May 05, 2013 at 01:33:45PM -0700, Linus Torvalds wrote:
> On Sun, May 5, 2013 at 4:03 AM, Ingo Molnar wrote:
> >
> > Please consider pulling the latest timers-nohz-for-linus git tree from:
>
> Ok, it seems to work for me, so pulled.
>
> However, by "work for me" I mean "doesn't actually
From: Stephen Hemminger
Date: Fri, 3 May 2013 17:49:41 -0700
> Programs using virtio headers outside of kernel will no longer
> build because u16 type does not exist in userspace. All user ABI
> must use __u16 typedef instead.
>
> Bug introduce by:
> commit
If memory allocation in ext4_mb_new_group_pa() is failed,
it returns error code, ext4_mb_new_preallocation() propages it,
but ext4_mb_new_blocks() ignores it.
An observed result was:
- allocation fail means ext4_mb_new_group_pa() does not update
ext4_allocation_context;
- ext4_mb_new_blocks()
After building 3.9 for my HP/Compaq 2510p laptop, the wireless (iwl4965)
would seemingly no longer connect. Actually, it seems that it *will*
eventually, where that is somewhere between 4 and 21+ retries (from KDE
network manager). Going back to 3.8 (and earlier) and the problem goes
away.
On Sun, May 05, 2013 at 10:24:22PM +0200, Alessandro Rubini wrote:
> > Did this got fixed in some tree in the meantime? Because I still see it on
> > current Linus + tip/master:
> >
> > arch/x86/pci/sta2x11-fixup.c:186:2: warning: initialization from
> > incompatible pointer type [enabled by
> Did this got fixed in some tree in the meantime? Because I still see it on
> current Linus + tip/master:
>
> arch/x86/pci/sta2x11-fixup.c:186:2: warning: initialization from incompatible
> pointer type [enabled by default]
> arch/x86/pci/sta2x11-fixup.c:186:2: warning: (near initialization for
On Sun, May 5, 2013 at 4:03 AM, Ingo Molnar wrote:
>
> Please consider pulling the latest timers-nohz-for-linus git tree from:
Ok, it seems to work for me, so pulled.
However, by "work for me" I mean "doesn't actually seem to make any
difference for me". Maybe I'm odd, but the most common
On Thu, May 02, 2013 at 05:16:15PM +0200, Arnd Bergmann wrote:
> This makes sure the conditionals for the declaration match the
> definition, so we provide the alternative
>
> #else
> #define IL_LEGACY_PM_OPS NULL
> #endif
>
> in the correct cases.
>
> drivers/built-in.o:(.data+0x57974):
On 05/05/2013 02:20 AM, tip-bot for Thomas Gleixner wrote:
> Commit-ID: ae7868e241c015aadc8632d9fe633a102a5918f6
> Gitweb: http://git.kernel.org/tip/ae7868e241c015aadc8632d9fe633a102a5918f6
> Author: Thomas Gleixner
> AuthorDate: Fri, 3 May 2013 15:02:50 +0200
> Committer: Thomas
Use the new generic usb-serial wait_until_sent implementation to wait
for hardware buffers to drain.
This removes the need to check the hardware buffers in chars_in_buffer
and thus removes the overhead introduced by commit 6f602912 ("usb:
serial: ftdi_sio: Add missing chars_in_buffer function")
No need to grab disconnect mutex in chars_in_buffer now that no
sub-driver is or should be querying hardware buffers anymore. (They
should use wait_until_sent.)
Signed-off-by: Johan Hovold
---
drivers/usb/serial/usb-serial.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
Use the new generic usb-serial wait_until_sent implementation to wait
for hardware buffers to drain.
This removes the need to check the hardware buffers in chars_in_buffer
and thus removes the overhead introduced by commit 263e1f9f ("USB:
io_ti: query hardware-buffer status in chars_in_buffer")
Add wait_until_sent operation which can be used to wait for hardware
buffers to drain.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/usb-serial.c | 17 +
include/linux/usb/serial.h | 1 +
2 files changed, 18 insertions(+)
diff --git a/drivers/usb/serial/usb-serial.c
Add generic wait_until_sent implementation which polls for empty
hardware buffers using the new port-operation tx_empty.
The generic implementation will be used for all sub-drivers that
implement tx_empty but does not define wait_until_sent.
Signed-off-by: Johan Hovold
---
These patches add wait_until_sent-support to usb-serial, which removes
the need to check hardware buffers in chars_in_buffer.
This fixes a problem in ftdi_sio (since 3.7) where select or TIOCMOUTQ
would take much longer than before due the hardware buffers being
queried.
Hardware buffers are
Use the new generic usb-serial wait_until_sent implementation to wait
for hardware buffers to drain.
This removes the need to check the hardware buffers in chars_in_buffer
and thus removes the overhead introduced by commit 2c992cd73 ("USB:
ti_usb_3410_5052: query hardware-buffer status in
Use usb-serial port rather than tty as argument to get_modem_status.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ftdi_sio.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 242b577..1159fd4
Konstantin Khlebnikov wrote:
> This patch fixes race between inet_frag_lru_move() and inet_frag_lru_add()
> which was introduced in commit 3ef0eb0db4bf92c6d2510fe5c4dc51852746f206
> ("net: frag, move LRU list maintenance outside of rwlock")
>
> One cpu already added new fragment queue into hash
On Sat, May 04, 2013 at 07:39:57AM -0400, Peter Hurley wrote:
> On 05/04/2013 07:15 AM, Johan Hovold wrote:
> > On Sat, May 04, 2013 at 01:50:42AM +0400, Stas Sergeev wrote:
> >> 04.05.2013 00:34, Greg KH пишет:
> >>> On Fri, May 03, 2013 at 10:27:18PM +0400, Stas Sergeev wrote:
> 03.05.2013
1 - 100 of 284 matches
Mail list logo
