[PATCH] lib: crc-itu-t: Fix typo in comment

Signed-off-by: David Mosberger-Tang --- lib/crc-itu-t.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/crc-itu-t.c b/lib/crc-itu-t.c index 1974b355c148..1d26a1647da5 100644 --- a/lib/crc-itu-t.c +++ b/lib/crc-itu-t.c @@ -7,7 +7,7 @@ #include #include -/** CRC table

[PATCH] lib: crc-itu-t: Fix comment in typo

Signed-off-by: David Mosberger-Tang --- lib/crc-itu-t.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/crc-itu-t.c b/lib/crc-itu-t.c index 1974b355c148..56e6e0d63d1e 100644 --- a/lib/crc-itu-t.c +++ b/lib/crc-itu-t.c @@ -7,7 +7,7 @@ #include #include -/** CRC table

[PATCH] drivers: nvmem: atmel-secumod: New driver for Atmel Secumod nvram

Signed-off-by: David Mosberger --- .../devicetree/bindings/nvmem/atmel-secumod.txt| 47 +++ drivers/nvmem/Kconfig | 7 + drivers/nvmem/Makefile | 2 + drivers/nvmem/atmel-secumod.c | 143 +++

[PATCH] drivers: nvmem: atmel-secumod: New driver for Atmel Secumod nvram

Signed-off-by: David Mosberger --- .../devicetree/bindings/nvmem/atmel-secumod.txt| 46 drivers/nvmem/atmel-secumod.c | 125 + 2 files changed, 171 insertions(+) create mode 100644 Documentation/devicetree/bindings/nvmem/atmel-secumod.txt c

Re: UBIFS recovery taking too long

Adrian, On Tue, Dec 10, 2013 at 12:25 AM, Adrian Hunter wrote: > Slowness is probably caused by trying to make free space. Was the file > system very full? A smaller journal might help. That's possible. We have not been able to reproduce the issue in house but a customer had it happen on sev

Fwd: UBIFS recovery taking too long

I've had no luck getting any response from the linux-mtd mailing list regarding the issue reported below. I think it is a very serious issue since it can easily render an embedded system unusable. --david -- Forwarded message -- From: David Mosberger-Tang Date: Thu,

Re: [patch 04/14] ia64: Remove the __SMALL_ADDR_AREA attribute for per cpu access

On 11/27/07, Christoph Lameter <[EMAIL PROTECTED]> wrote: > On Tue, 27 Nov 2007, David Mosberger-Tang wrote: > > > Uniformity for the sake of uniformity? The small data addressing is > > really elegant and I don't think it should be dropped just for the > > sak

Re: [patch 04/14] ia64: Remove the __SMALL_ADDR_AREA attribute for per cpu access

On 11/27/07, Christoph Lameter <[EMAIL PROTECTED]> wrote: > On Mon, 26 Nov 2007, David Mosberger-Tang wrote: > > > On 11/26/07, Christoph Lameter <[EMAIL PROTECTED]> wrote: > > > The model(small) attribute is not supported by gcc 4.X. The tests > > > will

Re: [patch 04/14] ia64: Remove the __SMALL_ADDR_AREA attribute for per cpu access

On 11/26/07, Christoph Lameter <[EMAIL PROTECTED]> wrote: > The model(small) attribute is not supported by gcc 4.X. The tests > will always be negative today. What was the rationale for removing this attribute? --david - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

Re: [PATCH] flush icache before set_pte() on ia64 take9 [2/2] flush icache at set_pte

On 8/10/07, Luck, Tony <[EMAIL PROTECTED]> wrote: > + if (pte_exec(pteval) &&// flush only new executable page. > + pte_present(pteval) && // swap out ? > + pte_user(pteval) &&// ignore kernel page > + (!pte_present(*ptep) ||// do_no_page or swap in, mig

Re: [PATCH] flush icache before set_pte take6. [4/4] optimization for cpus other than montecito

On 8/1/07, Zoltan Menyhart <[EMAIL PROTECTED]> wrote: > You do have model specific I cache semantics. > Not taking it into account will oblige you to flush in vain for the models > which do not require it. Why do you want to take this option? Given unlimited resources, your proposal makes perfect

Re: [PATCH] flush icache before set_pte take6. [4/4] optimization for cpus other than montecito

This seems crazy to me. Flushing should occur according to the *architecture*, not model-by-model. Even if we happen to get "lucky" on pre-Montecito CPUs, that doesn't justify such ugly hacks. Or you really want to debug this *again* come next CPU? --david On 7/30/07, KAMEZAWA Hiroyuki <[EMA

Re: Fw: [PATCH] ia64: race flushing icache in do_no_page path

My book has a fairly detailed discussion of how these operations were supposed to work and what the reasoning behind them was. Unfortunately, I don't have time to really participate this discussion at the moment, but I hope somebody else has access to the book and would (re-)read it for some backg

Re: [BUGFIX][PATCH] fixing placement of register stack under ulimit -s

But aren't you going to be limited to less than a page worth of register-backing store even with your patch applied because the backing store will end up overflowing the memory stack? --david On 3/15/07, KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote: This patch fixes ia64's bug in ulimit -s hand

Re: [patch] sched: unlocked context-switches

> Tony: >> Ingo: >> tested on x86, and all other arches should work as well, but if an >> architecture has irqs-off assumptions in its switch_to() logic it >> might break. (I havent found any but there may such assumptions.) > The ia64_switch_to() code includes a section that can change a