On Fri, May 3, 2013 at 5:43 PM, Christoph Lameter wrote:
> Subject: slab: Return NULL for oversized allocations
>
> The inline path seems to have changed the SLAB behavior for very large
> kmalloc allocations. This patch restores the old behavior but also
> adds diagnostics so that we can figure w
On Fri, May 03, 2013 at 16:32:47 +0200, Lee Jones wrote:
> The DMA platform data is now empty due to some recent refactoring,
> so there is no longer a requirement to pass it though.
>
> Acked-by: Arnd Bergmann
> Signed-off-by: Lee Jones
> ---
> arch/arm/mach-ux500/cpu-db8500.c |3 +--
> 1
On Sun, May 05, 2013 at 16:18:55 +0200, Dan Carpenter wrote:
> On Fri, May 03, 2013 at 12:37:14PM +0530, Srinidhi Kasagar wrote:
> > On Thu, May 02, 2013 at 17:48:10 +0200, Lee Jones wrote:
> > > drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c:
> > > In function ‘synaptics_rmi4_resume’:
> > >
On Mon, May 6, 2013 at 5:09 AM, Robert Hancock wrote:
>> and that's just within *one* of the fabless semiconductor companies,
>> and you have to bear in mind that there are *several hundred* ARM
>> licensees. when this topic was last raised, someone mentioned that
>> ARM attempted to standardise
On Fri, May 3, 2013 at 9:04 PM, Christoph Lameter wrote:
> Enabling various debugging options increases the size of structures and
> the subslab handling in SLABs kmem_cache_create will start to fail.
>
>
> Here is a fix for that:
>
> Subject: Fix bootstrap creation of kmalloc caches
>
> For SLAB
Hi Alex,
You might want to do the below for struct sched_entity also?
AFAIK,struct sched_entity has struct sched_avg under CONFIG_SMP.
Regards
Preeti U Murthy
On 05/06/2013 07:15 AM, Alex Shi wrote:
> The following variables were covered under CONFIG_SMP in struct cfs_rq.
> but similar runnable
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 r
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 Ghio
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 = se->
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, l
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 majord...@vger.kernel.
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 majord...@vger.kernel.or
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 reb
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: Jingo
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: Jingo
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: Jingo
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: Jingo
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
Acked-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: Jingo
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: Jingo
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: Jingo
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: Jingo
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: Jingo
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: Jingo
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: Jingo
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: Jingo
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 wh
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: Jingo
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: Jingo
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: Jingo
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: Jingo
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: Jingo
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: Jingo
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: Jingo
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: Jingo
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: Jingo
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: Jingo
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 tree
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: Jingo
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: Jingo
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: Jingo
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: Jingo
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: Jingo
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: Jingo
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 1006
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: Jingo
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: Jingo
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: Jingo
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: Jingo
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, t
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
> / cpu_rq(cpu)->avg.
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: Jingo
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
> enqueue
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 in
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 Documentation/devicetree/bindings/input/pxa27x-keypad
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 key
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
+++ b/arch/arm/mach-mmp/aspenite.
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
+++ b/arch/arm/mach-mmp/teton_b
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 |1
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 in
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
Sorry,
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 feedback!
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 u
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 --g
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 incorrect
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 inser
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 de
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 chang
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 kbui
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 other
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
--- a/dr
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
+++ b/drivers
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 s
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
mana
>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 i
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 6
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 `modsign_certif
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 986a4f4d452dec004697f667439d27c3fda9
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() set
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. (All
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 defa
> 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 situat
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): unde
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 Gleix
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") wi
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(-)
diff
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") wi
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 b
1 - 100 of 144 matches
Mail list logo
