headers
Thadeu Lima de Souza Cascardo | 5 Jul 00:30

[PATCH 2/3] Trivial: fix typo in label name s/Platofrm_finish/Platform_finish/

Although the same label name is used somewhere else in the file, this
particular label was consistently typoed in all of its uses.

Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo <at> holoscopio.com>
---
 kernel/power/hibernate.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index 81d2e74..ec82025 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -460,11 +460,11 @@ int hibernation_platform_enter(void)

 	error = hibernation_ops->prepare();
 	if (error)
-		goto Platofrm_finish;
+		goto Platform_finish;

 	error = disable_nonboot_cpus();
 	if (error)
-		goto Platofrm_finish;
+		goto Platform_finish;

 	local_irq_disable();
 	sysdev_suspend(PMSG_HIBERNATE);
@@ -476,7 +476,7 @@ int hibernation_platform_enter(void)
 	 * We don't need to reenable the nonboot CPUs or resume consoles, since
 	 * the system is going to be halted anyway.
 	 */
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thadeu Lima de Souza Cascardo | 5 Jul 00:26

[PATCH 1/3] Trivial: Fix filenames in their headers for the EMMA Mark-eins.

After some renaming, these filenames were not updated to reflect their
new locations.

Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo <at> holoscopio.com>
---
 arch/mips/emma/common/Makefile        |    2 +-
 arch/mips/emma/common/prom.c          |    2 +-
 arch/mips/emma/markeins/Makefile      |    2 +-
 arch/mips/emma/markeins/irq.c         |    2 +-
 arch/mips/emma/markeins/led.c         |    2 +-
 arch/mips/emma/markeins/platform.c    |    2 +-
 arch/mips/emma/markeins/setup.c       |    2 +-
 arch/mips/include/asm/emma/markeins.h |    2 +-
 8 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/mips/emma/common/Makefile b/arch/mips/emma/common/Makefile
index c392d28..faf73c3 100644
--- a/arch/mips/emma/common/Makefile
+++ b/arch/mips/emma/common/Makefile
@@ -1,5 +1,5 @@
 #
-#  arch/mips/emma2rh/common/Makefile
+#  arch/mips/emma/common/Makefile
 #       Makefile for the common code of NEC EMMA2RH based board.
 #
 #  Copyright (C) NEC Electronics Corporation 2005-2006
diff --git a/arch/mips/emma/common/prom.c b/arch/mips/emma/common/prom.c
index 120f53f..867b1cc 100644
--- a/arch/mips/emma/common/prom.c
+++ b/arch/mips/emma/common/prom.c
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rafael J. Wysocki | 5 Jul 00:21

[PATCH] PM / irq: Fix comment describing suspend_device_irqs()

From: Rafael J. Wysocki <rjw <at> sisk.pl>

The kerneldoc comment describing suspend_device_irqs() is currently
misleading, because generally the function doesn't really disable
interrupt lines at the chip level.  Replace it with a more accurate
one.

Signed-off-by: Rafael J. Wysocki <rjw <at> sisk.pl>
---
 kernel/irq/pm.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

Index: linux-2.6/kernel/irq/pm.c
===================================================================
--- linux-2.6.orig/kernel/irq/pm.c
+++ linux-2.6/kernel/irq/pm.c
@@ -15,10 +15,10 @@
 /**
  * suspend_device_irqs - disable all currently enabled interrupt lines
  *
- * During system-wide suspend or hibernation device interrupts need to be
- * disabled at the chip level and this function is provided for this purpose.
- * It disables all interrupt lines that are enabled at the moment and sets the
- * IRQ_SUSPENDED flag for them.
+ * During system-wide suspend or hibernation device drivers need to be prevented
+ * from receiving interrupts and this function is provided for this purpose.
+ * It marks all interrupt lines in use, except for the timer ones, as disabled
+ * and sets the IRQ_SUSPENDED flag for each of them.
  */
 void suspend_device_irqs(void)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julia Lawall | 4 Jul 23:30

[PATCH 3/3] drivers/vlynq/vlynq.c: Fix resource size off by 1 error

From: Julia Lawall <julia <at> diku.dk>

In this case, the calls to request_mem_region, ioremap, and
release_mem_region all have a consistent length argument, len, but since in
other files (res->end - res->start) + 1, equivalent to resource_size(res),
is used for a resource-typed structure res, one could consider whether the
same should be done here.

The problem was found using the following semantic patch:
(http://www.emn.fr/x-info/coccinelle/)

// <smpl>
@@
struct resource *res;
@@

- (res->end - res->start) + 1
+ resource_size(res)

@@
struct resource *res;
@@

- res->end - res->start
+ BAD(resource_size(res))
// </smpl>

Signed-off-by: Julia Lawall <julia <at> diku.dk>

---
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julia Lawall | 4 Jul 23:30

[PATCH 2/3] drivers/video/imxfb.c: Fix resource size off by 1 error

From: Julia Lawall <julia <at> diku.dk>

In the first case, the change is not semantics-preserving, but
resource_size is used at the corresponding call to request_mem_region in
the same function.

In the second case, the change is semantics-preserving.

The problem was found using the following semantic patch:
(http://www.emn.fr/x-info/coccinelle/)

// <smpl>
@@
struct resource *res;
@@

- (res->end - res->start) + 1
+ resource_size(res)

@@
struct resource *res;
@@

- res->end - res->start
+ BAD(resource_size(res))
// </smpl>

Signed-off-by: Julia Lawall <julia <at> diku.dk>

---
(Continue reading)

Permalink | Reply | 0 comments |
headers
Felix von Leitner | 4 Jul 22:35

Core i7 not scaling frequency down

Hi,

I just got a Nehalem CPU and it works OK except that the fans are always
running full power and it produces heat like an oven.

  $ cat /proc/acpi/processor/P001/info
  processor id:            0
  acpi id:                 1
  bus mastering control:   yes
  power management:        yes
  throttling control:      no
  limit interface:         no
  $

Oh, no throttling and no limit support?  How can this be?  I'm using
2.6.30 but this appears to be bogus; Windows scales down the CPU
frequency OK.

Does this mean my BIOS ACPI tables are bogus?

I get this message at boot time, but it appears to be unrelated:

  ACPI Warning (tbutils-0246): Incorrect checksum in table [OEMB] - 00, should be FE [20090320]

Any ideas what I could do now to get the CPU to slow down?

Thanks,

Felix
(Continue reading)

Permalink | Reply | 1 comment |
headers
honghanh | 4 Jul 19:40

(unknown)

Dear winner

Mr. james smith diretor of the department.i have been waiting
for you to contact me for your confirmable Bank Draft of (Two
Thousand Five Hundred Pounds)contact
fedexxpress.devlivery <at> live.com for your claims
Permalink | Reply | 0 comments |
headers
Linus Torvalds | 4 Jul 20:27

Linux 2.6.31-rc2


It's out there. Larger than I'd like, but the bulk of the changes are due 
to some late arch updates (MIPS, and powerpc documentation).

There's also a fair amount of somewhat scary i915 updates, but the bulk of 
that is the new displayport support which shouldn't regress (but with some 
i2c api changes and mode fixes to round it up).

There's also an intel-iommu merge that was larger than I hoped, but it 
fixes bugs that weren't fixable without some major cleanups (handling PAE 
high pages correctly on x86-32).

Other than that? Various changes all over. Drivers, networking, 
filesystems, perf-counters (more archictectures supported, but also some 
extensions), and yes, regression fixes.

I'm going to be a bit stricter about merge requests now. I really want 
-rc3 (and later) to be smaller than this.

So please do try it out, and remind people about regressions both new and 
old, ok?

		Linus

---
Aaro Koskinen (1):
      [ARM] 5560/1: Avoid buffer overrun in case of an invalid IRQ

Abhijeet Joglekar (1):
      [SCSI] fnic: use DMA_BIT_MASK(nn) instead of deprecated DMA_nnBIT_MASK
(Continue reading)

Permalink | Reply | 0 comments |
headers
Doug Graham | 4 Jul 20:27
Favicon

More fun with MinixFS V3

I was just looking over an old thread about MinixFs V3 support and
starting to get worried that my tweaks to support blocksizes of 512
bytes (for a small filesystem with many small files) might be broken.
This is the thread here: http://lkml.org/lkml/2006/5/6/50.
The nblocks() routine in fs/minix/itree_common.c now looks like this:

static inline unsigned nblocks(loff_t size, struct super_block *sb)
{
        int k = sb->s_blocksize_bits - 10;
        unsigned blocks, res, direct = DIRECT, i = DEPTH;
        blocks = (size + sb->s_blocksize - 1) >> (BLOCK_SIZE_BITS + k);
        ...

and what had be worred at first is that sb->s_blocksize_bits will be 9
with a blocksize of 512, which makes k negative.  But all may not be lost,
since k is only used once after this, after adding BLOCK_SIZE_BITS (10)
to it.  At least that makes it nonnegative again, but then the question
is: what exactly is being accomplished here?  First we subtract 10,
then add it back?  The result is effectively this:

  blocks = (size + sb->s_blocksize - 1) >> sb->s_blocksize_bits

which looks entirely correct to me.  Is there any reason the code couldn't
just be written this way to begin with?

--Doug
Permalink | Reply | 0 comments |
headers
honghanh | 4 Jul 19:44

(unknown)

Dear winner

Mr. james smith diretor of the department.i have been waiting
for you to contact me for your confirmable Bank Draft of (Two
Thousand Five Hundred Pounds)contact
fedexxpress.devlivery <at> live.com for your claims
Permalink | Reply | 0 comments |
headers
Richard Sharpe | 4 Jul 18:57

discard/UNMAP support: prepare_discard_fn does not pass enough info even in 2.6.31rc1

Hi,

I am trying to get BLKDICARD/unmap support working in SCST, and while
I have some code that works if I directly submit requests to
scst_local, things _seem_ broken above me.

There has been some support for BLKDISCARD requests for a number of
kernel releases already (starting about 2.6.28), but for UNMAP, and
probably any real support for DISCARD, we need to know the starting
sector and the range of sectors being discarded. However, at the point
at prepare_unmap_fn is called, that info has not been placed in the
request. Probably the simplest change would be to pass the bio to
prepare_discard_fn as well.

Matthew Wilcox published a patch that looks like it does close to the
right things here: http://lkml.org/lkml/2008/11/23/81

This passes the bio to prepare_discard_fn and has implemented a
discard function in sd.c so I do not have to do that work in my LLD,
but it seems to target an earlier version of the spec. I am working
with 08-149r9-3.pdf off of the T10 site.

Who should I contact about getting these changes merged or proposing a
different set of changes?

--

-- 
Regards,
Richard Sharpe
Permalink | Reply | 0 comments |

Gmane