v7: fixed things addressed by Dmitry Torokhov to v7 (quoted message goes below
the patch)
ideapad_slidebar is a new driver which enables slidebars on some
Lenovo IdeaPad laptops (the slidebars work with SlideNav/Desktop
Navigator under Windows)
Fixes this: https://bugzilla.kernel.org/show_bug.cg
On 2013/8/14 21:30, Tejun Heo wrote:
> Hello, Li.
>
> On Wed, Aug 14, 2013 at 10:01:32AM +0800, Li Zefan wrote:
>> But most controllers don't check this in those read/write functions.
>> It shoudn't do any harm not checking online/offline status.
>
> It depends on the specific controller. For co
>On 08/15/13 13:59, Mark Rutland wrote:
>> On Thu, Aug 15, 2013 at 12:03:02PM +0100, Jonathan Cameron wrote:
>>>
> The changes to the original driver:
> - device tree adaptation;
I couldn't see a binding document in this series or in mainline. Have I
looked in the wrong place
Hi Linus,
On Thu, 15 Aug 2013 17:33:28 -0700 Linus Torvalds
wrote:
>
> I'll probably delay committing it until tomorrow, in the hope that
> somebody using one of the other architectures will at least ack that
> it compiles. I'm re-attaching the patch (with the two "logn" -> "long"
> fixes) just
At Thu, 15 Aug 2013 14:27:07 -0600,
Nathanael D. Noblet wrote:
>
> Hello,
>
>I have hardware that suffers from an internal phase inverted mic that
> isn't properly detected. Below is a patch that fixes the issue for my
> particular hardware.
>
> Pre patch alsa-info:
>
> http://www.alsa-pr
On 08/14/2013 09:26:21 PM, Theodore Ts'o wrote:
As an experiment this year, the Linux Kernel Summit Program Committee
would like to put out a call for hobbyists. This year, we have up to
three places to give to people who do Linux Kernel development as a
hobby rather than a profession (Our defin
Hi Andrew,
After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
mm/built-in.o: In function `.__offline_pages.constprop.10':
memory_hotplug.c:(.ref.text+0x10ec): undefined reference to
`.is_hugepage_active'
Caused by commit 9a9137504d7c ("mm:
Around Fri 16 Aug 2013 07:55:01 +0530 or thereabout, Viresh Kumar wrote:
> Most of the drivers do following in their ->target_index() routines:
>
> struct cpufreq_freqs freqs;
> freqs.old = old freq...
> freqs.new = new freq...
>
> cpufreq_notify_transition(policy, &freqs,
>
> What happened to patch 1/3, I never got that.
>
You never got it, okay I'll resend it to 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 http://vger.kernel.org/majordomo-info.html
Plea
Following offline discussions with Sekhar, we discussed some ideas to
change a few things in this patch series to make it fail-safe. As such,
the only changes we are making for v4 will be to not cyclically link
immediately but doing so only once the ISR has finished setup (apart
from other style cl
hayeswang :
> Francois Romieu [mailto:rom...@fr.zoreil.com]
[...]
> > The forward declaration is not needed.
>
> The r8152_submit_rx() need the declaration of read_bulk_callback(), and the
> read_bulk_callback() need the declaration of r8152_submit_rx(), too. It likes
> a dead lock, so I have no
On Wed, Aug 14, 2013 at 10:33:33AM +0200, Nicolas Ferre wrote:
> Arnd, Olof, Kevin,
>
> This is the first (late) fixes pull-reqest for AT91. I would understand if
> you refuse it because we are already at -rc5 ;-) ...
>
> On the other hand, the line count is very low and all patches are pretty
>
On Thu, Aug 15, 2013 at 01:46:16PM +0400, Max Filippov wrote:
> Yes, xtensa compiler/linker is known to have issues with link-time
> relaxation; e.g. it may fail to build linux image without CONFIG_LD_NO_RELAX.
Is there something I can do at linker build time to help with this?
Yours Tony
pgp
On Thu, Aug 15, 2013 at 02:07:05AM -0700, Guenter Roeck wrote:
> Hi Tony,
>
> would it be possible to provide an arm64 cross-compiler on
> https://www.kernel.org/pub/tools/crosstool/ ?
I have one built I just need to upload it. I'll try and do it this
weekend.
> Also, the xtensa compiler fails
No functional change. The comment of function manage_workers()
RETURNS description is obvious wrong, same as the CONTEXT.
Fix it.
Signed-off-by: Libin
---
kernel/workqueue.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 7f5d
No functional changes. This patch fixes the post gcwq comments in
Documentation/workqueue.txt.
Signed-off-by: Libin
---
Documentation/workqueue.txt | 60 ++---
1 file changed, 29 insertions(+), 31 deletions(-)
diff --git a/Documentation/workqueue.txt b/Do
No functional change. There are two worker pools for each cpu in
current implementation(one for normal work items and the other for
high priority ones).
Signed-off-by: Libin
---
kernel/workqueue.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/kernel/workqueue.c b/kerne
We used to poll vhost queue before making DMA is done, this is racy if vhost
thread were waked up before marking DMA is done which can result the signal to
be missed. Fix this by always poll the vhost thread before DMA is done.
Signed-off-by: Jason Wang
---
drivers/vhost/net.c |9 +
Currently, even if the packet length is smaller than VHOST_GOODCOPY_LEN, if
upend_idx != done_idx we still set zcopy_used to true and rollback this choice
later. This could be avoided by determine zerocopy once by checking all
conditions at one time before.
Signed-off-by: Jason Wang
---
drivers/
Switch to use vhost_add_used_and_signal_n() to avoid multiple calls to
vhost_add_used_and_signal(). With the patch we will call at most 2 times
(consider done_idx warp around) compared to N times w/o this patch.
Signed-off-by: Jason Wang
---
drivers/vhost/net.c | 13 -
1 files chan
We used to limit the max pending DMAs to prevent guest from pinning too many
pages. But this could be removed since:
- We have the sk_wmem_alloc check in both tun/macvtap to do the same work
- This max pending check were almost useless since it was one done when there's
no new buffers coming fro
Let vhost_add_used() to use vhost_add_used_n() to reduce the code duplication.
Signed-off-by: Jason Wang
---
drivers/vhost/vhost.c | 43 ++-
1 files changed, 2 insertions(+), 41 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
ind
Hi all:
This series tries to unify and simplify vhost codes especially for zerocopy.
Plase review.
Thanks
Jason Wang (6):
vhost_net: make vhost_zerocopy_signal_used() returns void
vhost_net: use vhost_add_used_and_signal_n() in
vhost_zerocopy_signal_used()
vhost: switch to use vhost_a
None of its caller use its return value, so let it return void.
Signed-off-by: Jason Wang
---
drivers/vhost/net.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 969a859..280ee66 100644
--- a/drivers/vhost/net.c
+++ b/d
Hi Benoit,
On Tuesday 13 August 2013 08:18 PM, Benoit Cousson wrote:
> On 13/08/2013 16:45, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Tuesday 13 August 2013 06:51 PM, Benoit Cousson wrote:
>>> Hi Kishon,
>>>
>>> On 12/08/2013 11:37, Kishon Vijay Abraham I wrote:
SMPS10 has two outputs OUT
On Thu, Aug 15, 2013 at 09:53:25PM -0700, Guenter Roeck wrote:
> On 08/15/2013 12:55 AM, Geert Uytterhoeven wrote:
> > On Thu, Aug 15, 2013 at 9:43 AM, Guenter Roeck wrote:
> >> I screwed up my stable repo clone again :(, so the full build will take a
> >> bit.
> >>
> >> mips builds on on 3.4 with
I've applied this to the testing branch and moved to the better fsx in the
qa suite.
The ceph-fuse patches are still in wip-fallocate until I can run the fs
test suite against them.
Thanks!
sage
On Thu, 15 Aug 2013, Li Wang wrote:
> This patch implements fallocate and punch hole support for
On 15 August 2013 18:42, Wolfram Sang wrote:
> On Mon, Jul 01, 2013 at 12:25:19PM +0200, Tomasz Figa wrote:
>> Hi Naveen,
>>
>> Looks mostly good, but see some comments inline.
>
> Ping?
Hello Wolfram,
I made a patch fixing your comments and from Thomas Figa as well.
Meanwhile, we hit a random c
On Thu, 2013-08-15 at 18:09 +0100, Sudeep KarkadaNagesha wrote:
>/* Check for ibm,ppc-interrupt-server#s. If it doesn't exist
> * fallback to "reg" property and assume no threads
> */
> -
Oh and I forgot ... that comment is now wrong, since your co
Hi Minchan,
On Fri, Aug 16, 2013 at 12:26 PM, Minchan Kim wrote:
> Hi Mel,
>
> On Thu, Aug 15, 2013 at 06:12:50PM +0100, Mel Gorman wrote:
>> On Thu, Aug 15, 2013 at 03:58:20AM +0900, Minchan Kim wrote:
>> > >
>> > >
>> > > I do not believe this is a problem for zram as such because I do not
>>
On Thu, 2013-08-15 at 18:09 +0100, Sudeep KarkadaNagesha wrote:
> From: Sudeep KarkadaNagesha
>
> Currently different drivers requiring to access cpu device node are
> parsing the device tree themselves. Since the ordering in the DT need
> not match the logical cpu ordering, the parsing logic nee
On 08/15/2013 12:55 AM, Geert Uytterhoeven wrote:
On Thu, Aug 15, 2013 at 9:43 AM, Guenter Roeck wrote:
I screwed up my stable repo clone again :(, so the full build will take a
bit.
mips builds on on 3.4 with all patches applied now fail with:
arch/mips/include/asm/page.h: Assembler messages:
On Thu, Aug 15, 2013 at 04:39:27PM +0100, Mel Gorman wrote:
> If kswapd was reclaiming for a high order and resets it to 0 due to
> fragmentation it will still call compact_pgdat. For the most part, this will
> fail a compaction_suitable() test and not compact but it is unnecessarily
> sloppy. It c
Hi,
On Fri, Aug 16, 2013 at 10:02:08AM +0800, Wanpeng Li wrote:
> Hi Minchan,
> On Thu, Aug 15, 2013 at 01:17:53AM +0900, Minchan Kim wrote:
> >Hi Luigi,
> >
> >On Wed, Aug 14, 2013 at 08:53:31AM -0700, Luigi Semenzato wrote:
> >> During earlier discussions of zswap there was a plan to make it wor
Hi Mel,
On Thu, Aug 15, 2013 at 06:12:50PM +0100, Mel Gorman wrote:
> On Thu, Aug 15, 2013 at 03:58:20AM +0900, Minchan Kim wrote:
> > >
> > >
> > > I do not believe this is a problem for zram as such because I do not
> > > think it ever writes back to disk and is immune from the unpredictable
>
Fixed mis-use of mutex for gdm_table. gdm_table is refered to only
inside tty_install and port destrcut, and usb callbacks use internal
reference which was saved during urb submission
Signed-off-by: Won Kang
---
drivers/staging/gdm724x/gdm_mux.c |9
drivers/staging/gdm724x/gdm_mux.h
Removed the old style reference countings and termios.
Renamed variables to meaninful ones.
Signed-off-by: Won Kang
---
drivers/staging/gdm724x/gdm_tty.c | 294 ++---
drivers/staging/gdm724x/gdm_tty.h |5 +-
2 files changed, 142 insertions(+), 157 deletions(-
Hi Sergei,
On Fri, Aug 16, 2013 at 1:01 AM, Sergei Shtylyov
wrote:
> Hello.
>
>
> On 15-08-2013 10:01, Lad, Prabhakar wrote:
>
>> From: "Lad, Prabhakar"
>
>
>> Add OF_DEV_AUXDATA for eth0 driver in da850 board dt
>> file to use emac clock.
>
>
>> Signed-off-by: Lad, Prabhakar
>
> [...]
>
>
>>
Hi Sergei,
On Fri, Aug 16, 2013 at 1:00 AM, Sergei Shtylyov
wrote:
> Hello.
>
>
> On 15-08-2013 10:01, Lad, Prabhakar wrote:
>
>> From: "Lad, Prabhakar"
>
>
>> Add eth0 device tree node information and pinmux for mii to da850 by
>> providing interrupt details and local mac address of eth0.
>
>
>
Hi all,
This small patch introduce NUMA awaness to xen balloon driver.
It could be apply to
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
as far as I send this email.
And it's version 2, since the first version is too urgly.
Francois Romieu [mailto:rom...@fr.zoreil.com]
> Sent: Thursday, August 15, 2013 8:26 PM
> To: Hayeswang
> Cc: net...@vger.kernel.org; nic_swsd;
> linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; David Miller
> Subject: Re: [PATCH net-next v2 1/3] net/usb/r8152: support
> aggregation
>
[
Hi Benoit ,
Thanks for your review.
On 8/14/2013 8:04 PM, Benoit Cousson wrote:
+ Roger
Hi George,
Yes, I had some comment about the "ti'type" in Roger's series that
will be applicable here as well.
On 14/08/2013 16:16, George Cherian wrote:
+Benoit
If you dont have any comments, c
I am Mrs. Rachael Tims. I have Cancer of the Lungs. I would like to share a
secret with you. Contact my Attorney Thomas Belford with this specified email:
i...@nobelchb.org kindly state that I have WILLED $10,000,000.00 to you
--
To unsubscribe from this list: send the line "unsubscribe linux-ker
> > +blkdevparts=[;]
> > + := :[,]
> > + := [@](part-name)
> > +
> > +
> > +block device disk name, embedded device used fixed block device,
> > +it's disk name also fixed. such as: mmcblk0, mmcblk1, mmcblk0boot0.
>
> The device-name isn't always fixed.
>
> For example, what if ther
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with &of_dev->dev,
so we can directly pass a struct platform_device.
changelog:
remove modify about happy_meal_pci_probe && happy_meal_pci_remove
Signed-off-by:
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_tr
Another 452 lines gone :)
Total stats upto now for all the 5 patchsets:
Viresh Kumar (186):
...
69 files changed, 700 insertions(+), 2451 deletions(-)
Net: 1751 lines gone..
-x-x
Most of the drivers do following in their ->target_index() routines:
struct
Why are the LZ4 symbols being GPL-exported when the LZ4 code is
BSD-licensed and no substantial changes appear to have been made when it
was merged?
Also, why is the module license GPL when the code itself is clearly
under a BSD license?
signature.asc
Description: OpenPGP digital signature
These registration calls may be used by loadable modules. Export them.
Signed-off-by: Mike Turquette
---
drivers/clk/clk-fixed-factor.c | 2 ++
drivers/clk/clk-gate.c | 1 +
drivers/clk/clk-mux.c | 2 ++
3 files changed, 5 insertions(+)
diff --git a/drivers/clk/clk-fixed-factor
The following changes since commit d4e4ab86bcba5a72779c43dc1459f71fea3d89c8:
Linux 3.11-rc5 (2013-08-11 18:04:20 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/
tags/usb-3.11-rc6
for you to fetch changes up to ff8a43c10f1440f07a5
On Thu, Aug 15, 2013 at 07:07:10PM -0700, Greg KH wrote:
> The following changes since commit d4e4ab86bcba5a72779c43dc1459f71fea3d89c8:
>
> Linux 3.11-rc5 (2013-08-11 18:04:20 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/
Hi,
On 8/5/13 6:31 PM, Christian Ruppert wrote:> On Wed, Jul 24, 2013 at 11:31:44PM
+0900, Shinya Kuribayashi wrote:
As said before, all t_SCL things should go away. Please forget
about 100kbps, 400kbps, and so on. Bus/clock speed is totally
pointless concept for the I2C bus systems. For exa
On Thu, 2013-08-15 at 18:23 +0200, Alexander Gordeev wrote:
> On Fri, Aug 09, 2013 at 01:17:37PM -0700, Nicholas A. Bellinger wrote:
> > On Fri, 2013-08-09 at 21:15 +0200, Alexander Gordeev wrote:
> > Mmmm, I'm able to reproduce over here with ahci + scsi-mq, and it
> > appears to be a bug related
The following changes since commit d4e4ab86bcba5a72779c43dc1459f71fea3d89c8:
Linux 3.11-rc5 (2013-08-11 18:04:20 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/
tags/usb-3.11-rc6
for you to fetch changes up to ff8a43c10f1440f07a5
Hi Mel,
On 08/16/2013 01:12 AM, Mel Gorman wrote:
> On Thu, Aug 15, 2013 at 03:58:20AM +0900, Minchan Kim wrote:
>>>
>>>
>>> I do not believe this is a problem for zram as such because I do not
>>> think it ever writes back to disk and is immune from the unpredictable
>>> performance characterist
Hi Mel,
On 08/16/2013 01:12 AM, Mel Gorman wrote:
> On Thu, Aug 15, 2013 at 03:58:20AM +0900, Minchan Kim wrote:
>>>
>>>
>>> I do not believe this is a problem for zram as such because I do not
>>> think it ever writes back to disk and is immune from the unpredictable
>>> performance characterist
Hi David,
Today's linux-next merge of the dlm tree got a conflict in fs/dlm/user.c
between commit 201d3dfa4da1 ("dlm: kill the unnecessary and wrong
device_close()->recalc_sigpending()") from Linus' tree and commit
c6ca7bc91d51 ("dlm: remove signal blocking") from the dlm tree.
I fixed it up (the
On Thu, 2013-08-15 at 12:29 -0700, Andrew Morton wrote:
> On Thu, 15 Aug 2013 09:59:42 -0700 Davidlohr Bueso wrote:
>
> > On Tue, 2013-08-06 at 14:16 -0700, Andrew Morton wrote:
> > > On Mon, 5 Aug 2013 22:21:08 -0700 Davidlohr Bueso
> > > wrote:
> > >
> > > > This patchset teaches the kernel
On Thu, Aug 15, 2013 at 06:28:34PM -0700, Guenter Roeck wrote:
> On 08/15/2013 06:22 PM, Greg Kroah-Hartman wrote:
> >> That was "fixed" by a complete arm Kconfig overhaul. I don't think you want
> >> that in 3.4.
> >> --
> >
> > Not a "complete" overhaul, no. But getting a default all
On 08/14, Mike Turquette wrote:
> Quoting Stephen Boyd (2013-08-12 22:48:39)
> > On 08/12, Mike Turquette wrote:
> > > Quoting Stephen Boyd (2013-07-24 17:43:31)
> > > > In similar fashion as of_regulator_match() add an of_clk_match()
> > > > function that finds an initializes clock init_data struc
On 08/15/2013 06:22 PM, Greg Kroah-Hartman wrote:
On Thu, Aug 15, 2013 at 07:45:12AM -0700, Guenter Roeck wrote:
On 08/14/2013 11:36 PM, Greg Kroah-Hartman wrote:
On Wed, Aug 14, 2013 at 03:14:11AM -0700, Guenter Roeck wrote:
On 08/14/2013 01:26 AM, Geert Uytterhoeven wrote:
On Wed, Aug 14, 2
On Thu, Aug 15, 2013 at 6:07 PM, Lee Jones wrote:
>> >> +Optional parent device properties:
>> >> +- marvell,88pm800-irq-write-clear: inicates whether interrupt status is
>> >> cleared by write
>> >> +- marvell,88pm800-battery-detection: indicats whether need 88pm800 to
>> >> support battery
>>
On Thu, Aug 15, 2013 at 07:45:12AM -0700, Guenter Roeck wrote:
> On 08/14/2013 11:36 PM, Greg Kroah-Hartman wrote:
> > On Wed, Aug 14, 2013 at 03:14:11AM -0700, Guenter Roeck wrote:
> >> On 08/14/2013 01:26 AM, Geert Uytterhoeven wrote:
> >>> On Wed, Aug 14, 2013 at 12:36 AM, Guenter Roeck
> >>>
On Thu, Aug 15, 2013 at 08:12:10AM -0700, Guenter Roeck wrote:
> On 08/14/2013 11:36 PM, Greg Kroah-Hartman wrote:
> > On Wed, Aug 14, 2013 at 03:14:11AM -0700, Guenter Roeck wrote:
> >> On 08/14/2013 01:26 AM, Geert Uytterhoeven wrote:
> >>> On Wed, Aug 14, 2013 at 12:36 AM, Guenter Roeck
> >>>
On 2013/8/16 6:23, David Miller wrote:
> From: Libo Chen
> Date: Thu, 15 Aug 2013 21:01:47 +0800
>
>> Use the wrapper functions for getting and setting the driver data using
>> platform_device instead of using dev_{get,set}_drvdata() with &of_dev->dev,
>> so we can directly pass a struct platform
On 08/15/2013 05:58 PM, Greg Kroah-Hartman wrote:
On Thu, Aug 15, 2013 at 02:07:35AM -0700, Guenter Roeck wrote:
On 08/14/2013 11:36 PM, Greg Kroah-Hartman wrote:
On Wed, Aug 14, 2013 at 03:14:11AM -0700, Guenter Roeck wrote:
On 08/14/2013 01:26 AM, Geert Uytterhoeven wrote:
On Wed, Aug 14, 2
On Thu, Aug 15, 2013 at 02:07:35AM -0700, Guenter Roeck wrote:
> On 08/14/2013 11:36 PM, Greg Kroah-Hartman wrote:
> > On Wed, Aug 14, 2013 at 03:14:11AM -0700, Guenter Roeck wrote:
> >> On 08/14/2013 01:26 AM, Geert Uytterhoeven wrote:
> >>> On Wed, Aug 14, 2013 at 12:36 AM, Guenter Roeck
> >>>
1 - 100 of 533 matches
Mail list logo