headers
David Woodhouse | 1 Aug 2011 01:09
Favicon

Re: [PATCH 1/5] um: Use __i386__ in ifdef for vsyscall exports, not SUBARCH_i386

On Sun, 2011-07-31 at 23:48 +0100, Al Viro wrote:
> Hell, no.  If you want to do it, do it the right way.  See #x86_merge in
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/um-header.git/

 255 files changed, 6848 insertions(+), 7816 deletions(-)

Absolutely, but slightly out of scope for what I was trying to do :)

I just posted a *minimal* set of changes to make the UML build system
cope; fixing the code as you've done is *definitely* the better option.
Is there a reason it didn't go upstream yet?

It just wants this, to make the CONFIG_64BIT option visible when
SUBARCH=x86 and also put it *first*.

diff --git a/arch/um/Kconfig.x86 b/arch/um/Kconfig.x86
index d31ecf3..630db12 100644
--- a/arch/um/Kconfig.x86
+++ b/arch/um/Kconfig.x86
 <at>  <at>  -1,5 +1,19  <at>  <at> 
 mainmenu "User Mode Linux/$SUBARCH $KERNELVERSION Kernel Configuration"

+config 64BIT
+	bool "Build 64-bit kernel" if SUBARCH = "x86"
+	default SUBARCH != "i386"
+        ---help---
+          Say yes to build a 64-bit kernel - formerly known as x86_64
+          Say no to build a 32-bit kernel - formerly known as i386
+
+config X86_32
(Continue reading)

Permalink | Reply | 0 comments |
headers
Axel Lin | 1 Aug 2011 01:23
Picon
Gravatar

[PATCH] power_supply: fix unterminated platform_device_id table for max8997_charger and max8998_charger

The platform_device_id table is supposed to be zero-terminated.

Signed-off-by: Axel Lin <axel.lin <at> gmail.com>
---
 drivers/power/max8997_charger.c |    1 +
 drivers/power/max8998_charger.c |    1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/power/max8997_charger.c b/drivers/power/max8997_charger.c
index 7106b49..9848fb8 100644
--- a/drivers/power/max8997_charger.c
+++ b/drivers/power/max8997_charger.c
 <at>  <at>  -177,6 +177,7  <at>  <at>  static int __devexit max8997_battery_remove(struct platform_device *pdev)

 static const struct platform_device_id max8997_battery_id[] = {
 	{ "max8997-battery", 0 },
+	{ }
 };

 static struct platform_driver max8997_battery_driver = {
diff --git a/drivers/power/max8998_charger.c b/drivers/power/max8998_charger.c
index cc21fa2..4ddacb4 100644
--- a/drivers/power/max8998_charger.c
+++ b/drivers/power/max8998_charger.c
 <at>  <at>  -188,6 +188,7  <at>  <at>  static int __devexit max8998_battery_remove(struct platform_device *pdev)

 static const struct platform_device_id max8998_battery_id[] = {
 	{ "max8998-battery", TYPE_MAX8998 },
+	{ }
 };
(Continue reading)

Permalink | Reply | 0 comments |
headers
Axel Lin | 1 Aug 2011 01:29
Picon
Gravatar

[PATCH -next] power: max8997_charger.c needs module.h

power/max8997_charger.c uses interfaces from linux/module.h,
so it should include that file.  This fixes build errors.

Signed-off-by: Axel Lin <axel.lin <at> gmail.com>
---
 drivers/power/max8997_charger.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/power/max8997_charger.c b/drivers/power/max8997_charger.c
index 9848fb8..e12b4a2 100644
--- a/drivers/power/max8997_charger.c
+++ b/drivers/power/max8997_charger.c
 <at>  <at>  -20,6 +20,7  <at>  <at> 
  */

 #include <linux/err.h>
+#include <linux/module.h>
 #include <linux/slab.h>
 #include <linux/platform_device.h>
 #include <linux/power_supply.h>
--

-- 
1.7.4.1
Permalink | Reply | 2 comments |
headers
Axel Lin | 1 Aug 2011 01:41
Picon
Gravatar

[PATCH] power_supply: max8998_charger: allow full timeout not set, leave it unchanged

Add a missing break for case 0 of pdata->timeout, otherwise it will fall
through to the default case and return error.

Signed-off-by: Axel Lin <axel.lin <at> gmail.com>
---
 drivers/power/max8998_charger.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/power/max8998_charger.c b/drivers/power/max8998_charger.c
index 4ddacb4..f793711 100644
--- a/drivers/power/max8998_charger.c
+++ b/drivers/power/max8998_charger.c
 <at>  <at>  -152,6 +152,7  <at>  <at>  static __devinit int max8998_battery_probe(struct platform_device *pdev)
 	case 0:
 		dev_dbg(max8998->dev,
 			"Full Timeout not set: leave it unchanged.\n");
+		break;
 	default:
 		dev_err(max8998->dev, "Invalid Full Timeout value\n");
 		ret = -EINVAL;
--

-- 
1.7.4.1
Permalink | Reply | 4 comments |
headers
Coly Li | 1 Aug 2011 01:52
Picon

Re: [PATCH 0/2] Add inode checksum support to ext4

On 2011年07月31日 15:08, Joel Becker Wrote:
> On Sat, Jul 30, 2011 at 03:25:32PM +0800, Coly Li wrote:
>> On 2011年07月29日 21:19, Joel Becker Wrote:
>>> On Fri, Jul 29, 2011 at 03:48:45AM -0600, Andreas Dilger wrote:
>>>> On 2011-07-28, at 4:07 PM, Joel Becker wrote:
>>>>> 	We use ethernet crc32 in ocfs2.  btrfs uses crc32c.  Frankly, I
>>>>> could have used crc32c if I'd really thought about the hardware
>>>>> acceleration benefits.  I think it's a good idea for ext4.
>>>>
>>>> The problem with crc32[c] is that if you don't have hardware acceleration
>>>> it is terribly slow.
>>>
>>> 	We find ethernet crc32 just fine in ocfs2.  I use the kernel's
>>> implementation, which survives everyone's network traffic, and of course
>>> we added the triggers to jbd2 so we only have to do the calculations on
>>> read and write.
>>>
>>
>> Ext4 supports non-journal mode, and there are a few users (Google, Taobao, etc.).
>> A trigger of jbd2 may not work well for non-journal Ext4 ...
>>
>> And in non-journal mode, there is not copy of any meta data block in jbd2, we need to be
>> more careful in check summing, e.g. inode/block bitmap blocks...
> 
> 	Sure, but you could use a trigger in journaled mode and then do
> the checksums directly in the __ext4_handle_journal_dirty_*() functions
> in non-journaled mode.  Sure, it would be a little more CPU time, but
> the user picked "checksums + no journal" at mkfs time.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Brown | 1 Aug 2011 02:29
Favicon
Gravatar

Re: [PATCH] cpufreq: Fix build of s3c64xx cpufreq driver for header change

On Sat, Jul 30, 2011 at 01:44:25PM -0400, Paul Gortmaker wrote:
> On 11-07-29 11:19 AM, Mark Brown wrote:

> > Some header change has removed an implicit include of module.h, breaking
> > the build due to the use of THIS_MODULE. Fix that.

> Thanks, I'll apply it to the module.h cleanup branch that is soaking
> in linux-next.

There's a bunch of other changes fixing issues with this floating around
- Randy Dunlap sent something for a regulator driver the other day and
I've got a couple of other Samsung patches I sent on the basis that this
must have been caused by a change in the Samsung headers.
Permalink | Reply | 3 comments |
headers
Linus Torvalds | 1 Aug 2011 02:45
Gravatar

Re: [GIT] [3.1] MFD pull request

On Sun, Jul 31, 2011 at 12:37 PM, Samuel Ortiz <sameo <at> linux.intel.com> wrote:
>
> This is the MFD pull request for the 3.1 merge window.

Guys, I'm getting *really* fed up with these kinds of trees.

This -git tree clearly had no testing at all, and cannot possibly have
been in -next.

How do I know? It's based on something I pushed out this morning, so
all the commits are really recent.

DO NOT DO THIS. It annoys the hell out of me to pull something and be
able to definitely say immediately that the person who wrote the pull
request clearly gave that particular git tree zero amount of actual
testing.

I pulled this time, because I just cannot find it in myself to care
too much about mfd.

But for the very same reason, next time I notice people rebasing their
trees on top of random points, I will just not pull.  If I see that
the tree they based stuff on is from the merge window, I'll just go
"this guy clearly means for this to get more testing, and meant for
this to be pulled in *next* merge window".

And it doesn't matter one whit if you say something like "Oh, but I
use quilt, so it's been tested there, and I just imported a very well
tested tree into -git to push it to you". Dammit, even if you use
quilt or something else to actually maintain your patch series, I KNOW
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yung, Winson W | 1 Aug 2011 03:08
Picon
Favicon

RE: [PATCH] [RFC] ondemand governor: dynamic cpufreq scaling with different CPUs

Thanks Venki for the comment, here is my thoughts on the change:

Correct me if I am wrong, it is probably true on PC that hw (bios) coordination mode for p-state is better over
sw coordination mode, however on smartphone/tablet devices, there is no BIOS, so sw coordination mode is
the only choice.

I am not sure I can simplify the change inside do_dbs_timer per your comment, dbs_info is per cpu, how are
other CPUs suppose to see cpu change without getting that CPU's dbs_info? That's why I store the cpu and
dbs_timer interval info inside policy which shared by all CPUs.

Having said that, how to handle cpu hotplug is something that my patch didn't do. If I offline one cpu and then
online it again, it will no longer participate do_dbs_timer call. The code to add it back to dbs_timer cpus
list and use the same shared policy is somewhat complicated. I am hoping to get some better idea on this from
the community.  

BTW, this delayed work queue problem should exist in both ondemand and conservative governors.

/Winson

>-----Original Message-----
>From: Venkatesh Pallipadi [mailto:venki <at> google.com]
>Sent: Friday, July 29, 2011 9:53 AM
>To: Yung, Winson W
>Cc: linux-kernel <at> vger.kernel.org; Van De Ven, Arjan
>Subject: Re: [PATCH] [RFC] ondemand governor: dynamic cpufreq scaling
>with different CPUs
>
>On Tue, Jul 26, 2011 at 10:22 AM, Yung, Winson W
><winson.w.yung <at> intel.com> wrote:
>>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Yong Zhang | 1 Aug 2011 03:33
Picon

Re: [PATCH] sched: Remove WAKEUP_PREEMPT feature check in entity_tick

On Fri, Jul 29, 2011 at 01:45:33PM +0200, Peter Zijlstra wrote:
> On Fri, 2011-07-29 at 16:46 +0800, Yong Zhang wrote:
> > Let's take UP for example, we have cpu-hug task A and threadirq B.
> > 
> >         n tick          --->            n+1 tick
> > set_tsk_need_resched(A);
> >                 B comes in and
> >                 wake up thread-B;
> > 
> > So for system on which we disable WAKEUP_PREEMPT,
> > if we don't have that check, thread-B will wait until n+1 tick comes
> > to get to run.
> > But if we have that check, thread-B will get to run after IRQ-B returns.
> 
> But that's exactly what wakeup preemption is about, waking tasks don't
> get to preempt running tasks. So no doing that preemption is exactly
> right for !WAKEUP_PREEMPT.
> 
> Anyway, I've queued the removal patch since that removes all
> confusion ;-)

Yup, that sounds good. Thanks Peter.

-Yong

--

-- 
Only stand for myself
Permalink | Reply | 0 comments |
headers
Linus Torvalds | 1 Aug 2011 03:40
Gravatar

Re: xfstests 073 regression

On Sun, Jul 31, 2011 at 3:28 PM, Dave Chinner <david <at> fromorbit.com> wrote:
>
> IOWs, what I'm asking is whether this "just move the inodes one at a
> time to a different queue" is just a bandaid for a particular
> symptom of a deeper problem we haven't realised existed....

Deeper problems in writeback? Unpossible.

The writeback code has pretty much always been just a collection of
"bandaids for particular symptoms of deeper problems".  So let's just
say I'd not be shocked. But what else would you suggest? You could
just break out of the loop if you can't get the read lock, but while
the *common* case is likely that a lot of the inodes are on the same
filesystem, that's certainly not the only possible case.

                 Linus
Permalink | Reply | 12 comments |

Gmane