On Wed, 2008-02-13 at 00:48 -0800, Andrew Morton wrote:
> On Tue, 12 Feb 2008 22:46:01 +1100 Ben Nizette <[EMAIL PROTECTED]> wrote:
> > Perfectly repeatable.
>
> If my theory is correct, changing pretty much anything in the kernel config
> might just make it go aw
On Wed, 2008-02-13 at 00:48 -0800, Andrew Morton wrote:
On Tue, 12 Feb 2008 22:46:01 +1100 Ben Nizette [EMAIL PROTECTED] wrote:
Perfectly repeatable.
If my theory is correct, changing pretty much anything in the kernel config
might just make it go away. But still, it would be most
On an AVR32, root over NFS, config attached, running (from a startup
script):
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Results in (dmesg extract including a bit of context for good measure):
-8<
VFS: Mounted root (nfs filesystem).
Freeing init memory: 72K
On an AVR32, root over NFS, config attached, running (from a startup
script):
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Results in (dmesg extract including a bit of context for good measure):
-8
VFS: Mounted root (nfs filesystem).
Freeing init memory: 72K
the hood up, remove a duplicate declaration of
at32_add_device_twi() in board.h.
Signed-Off-By: Ben Nizette <[EMAIL PROTECTED]>
---
Index: linux-2.6.23.atmel.4/arch/avr32/boards/atngw100/setup.c
===
--- linux-2.6.23.atmel.4.orig/arch
the hood up, remove a duplicate declaration of
at32_add_device_twi() in board.h.
Signed-Off-By: Ben Nizette [EMAIL PROTECTED]
---
Index: linux-2.6.23.atmel.4/arch/avr32/boards/atngw100/setup.c
===
--- linux-2.6.23.atmel.4.orig/arch/avr32
Haavard Skinnemoen wrote:
> On Wed, 23 Jan 2008 22:53:54 +1100
> Ben Nizette <[EMAIL PROTECTED]> wrote:
>
>> /*
>> + * We just keep an empty definition of this around (a-la the asm-generic
>> + * implementation) to keep /dev/mem happy
>> + */
>> +#de
Haavard Skinnemoen wrote:
On Wed, 23 Jan 2008 22:53:54 +1100
Ben Nizette [EMAIL PROTECTED] wrote:
/*
+ * We just keep an empty definition of this around (a-la the asm-generic
+ * implementation) to keep /dev/mem happy
+ */
+#define unxlate_dev_mem_ptr(p, a) {}
Thanks, but this should
Haavard Skinnemoen wrote:
Hmm...I can't see anything like this on my current avr32-arch branch,
but I think I mistakenly pushed out some unfinished code about a week
ago and rewound it shortly afterwards. If Andrew pulled during that
window, I guess it must have made it into -mm :-(
But thanks
Some parts of this function use 'page', some 'pte'. As such, an AVR32
-mm build fails with an undefined reference to 'page'.
Signed-Off-By: Ben Nizette <[EMAIL PROTECTED]>
---
Index: linux-2.6.24-rc8-mm1/include/asm-avr32/pga
Defined as a NOP on AVR32 as per the asm-generic implementation.
This keeps /dev/mem happy.
Signed-Off-By: Ben Nizette <[EMAIL PROTECTED]>
---
Index: linux-2.6.24-rc8-mm1/include/asm-avr32/io.h
===
--- linux-2.6.24-rc8-mm
Defined as a NOP on AVR32 as per the asm-generic implementation.
This keeps /dev/mem happy.
Signed-Off-By: Ben Nizette [EMAIL PROTECTED]
---
Index: linux-2.6.24-rc8-mm1/include/asm-avr32/io.h
===
--- linux-2.6.24-rc8-mm1.orig
Some parts of this function use 'page', some 'pte'. As such, an AVR32
-mm build fails with an undefined reference to 'page'.
Signed-Off-By: Ben Nizette [EMAIL PROTECTED]
---
Index: linux-2.6.24-rc8-mm1/include/asm-avr32/pgalloc.h
Haavard Skinnemoen wrote:
Hmm...I can't see anything like this on my current avr32-arch branch,
but I think I mistakenly pushed out some unfinished code about a week
ago and rewound it shortly afterwards. If Andrew pulled during that
window, I guess it must have made it into -mm :-(
But thanks
Haavard Skinnemoen wrote:
On Mon, 14 May 2007 17:18:06 +0200
Pierre Ossman <[EMAIL PROTECTED]> wrote:
New suggestion.
Works wonderfully here:
Waiting for root device /dev/mmcblk0p1...
mmcblk0: mmc0:a95c SD128 123008KiB
mmcblk0: p1
VFS: Mounted root (ext2 filesystem).
Of course, it also
Haavard Skinnemoen wrote:
On Mon, 14 May 2007 17:18:06 +0200
Pierre Ossman [EMAIL PROTECTED] wrote:
New suggestion.
Works wonderfully here:
Waiting for root device /dev/mmcblk0p1...
inserts card
mmcblk0: mmc0:a95c SD128 123008KiB
mmcblk0: p1
VFS: Mounted root (ext2 filesystem).
Of course,
Stephane Jourdois wrote:
On Mon, Mar 19, 2007 at 08:56:23PM -0800, Andrew Morton wrote:
Temporarily at
http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/
[..]
+complain-about-missing-system-calls.patch
+complain-about-missing-system-calls-update.patch
Hi,
I needed the following patch to
Stephane Jourdois wrote:
On Mon, Mar 19, 2007 at 08:56:23PM -0800, Andrew Morton wrote:
Temporarily at
http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/
[..]
+complain-about-missing-system-calls.patch
+complain-about-missing-system-calls-update.patch
Hi,
I needed the following patch to
NZG wrote:
I'm developing an SPI- bus >MMC/SD block driver translation layer.
As part of this layer the write protect and card detect lines need to be read.
The method for determining the state of these lines will be board specific.
Is it appropriate to pass a function pointer through a
NZG wrote:
I'm developing an SPI- bus MMC/SD block driver translation layer.
As part of this layer the write protect and card detect lines need to be read.
The method for determining the state of these lines will be board specific.
Is it appropriate to pass a function pointer through a platform
David Brownell wrote:
With the || AVR32 I've added to my version it's getting a bit out of
hand! Anyone else think it would be worth introducing a GPIO_FRAMEWORK
symbol selected by each machine which supports it and just set the
gpio_keys dependency to that?
Earlier today I posted a patch
David Brownell wrote:
The gpio_keys driver is wrongly ARM-specific; it can't build on
other platforms with GPIO suport. This fixes that problem.
I did up a similar patch a few days back, you beat me too it ;). I've
been using this driver on AVR32 for a while now.
The other thing was that
David Brownell wrote:
The gpio_keys driver is wrongly ARM-specific; it can't build on
other platforms with GPIO suport. This fixes that problem.
I did up a similar patch a few days back, you beat me too it ;). I've
been using this driver on AVR32 for a while now.
The other thing was that
David Brownell wrote:
With the || AVR32 I've added to my version it's getting a bit out of
hand! Anyone else think it would be worth introducing a GPIO_FRAMEWORK
symbol selected by each machine which supports it and just set the
gpio_keys dependency to that?
Earlier today I posted a patch
v j wrote:
This is in reference to the following thread:
http://lkml.org/lkml/2006/12/14/63
I am not sure if this is ever addressed in LKML, but linux is _very_
popular in the embedded space. We (an embedded vendor) chose Linux 3
years back because of its lack of royalty model, robustness and
v j wrote:
This is in reference to the following thread:
http://lkml.org/lkml/2006/12/14/63
I am not sure if this is ever addressed in LKML, but linux is _very_
popular in the embedded space. We (an embedded vendor) chose Linux 3
years back because of its lack of royalty model, robustness and
Joe Perches wrote:
Now that most of the sizeof(array)/sizeof(array[0])
conversions have been done (there are about 800 done
and about another 130 left), perhaps it could be
useful to change the code to use a define similar
to the list_for_each
#define list_for_each(pos, head) \
for (pos
Joe Perches wrote:
Now that most of the sizeof(array)/sizeof(array[0])
conversions have been done (there are about 800 done
and about another 130 left), perhaps it could be
useful to change the code to use a define similar
to the list_for_each
#define list_for_each(pos, head) \
for (pos
Wu, Bryan wrote:
Hi everyone,
This is the Blackfin architecture patch against Linux kernel 2.6.20,
again. As we promised, some issues are fixed in the latest release with
the help from lkml.
The blackfin-arch patch is at
https://blackfin.uclinux.org/gf/download/frsrelease/25/2490/blackfin-arc
Wu, Bryan wrote:
Hi everyone,
This is the Blackfin architecture patch against Linux kernel 2.6.20,
again. As we promised, some issues are fixed in the latest release with
the help from lkml.
The blackfin-arch patch is at
https://blackfin.uclinux.org/gf/download/frsrelease/25/2490/blackfin-arc
Wu, Bryan wrote:
Hi everyone,
This is the Blackfin architecture patch against Linux kernel 2.6.20,
again. As we promised, some issues are fixed in the latest release with
the help from lkml.
The blackfin-arch patch is at
https://blackfin.uclinux.org/gf/download/frsrelease/25/2490/blackfin-arc
Wu, Bryan wrote:
Hi everyone,
This is the Blackfin architecture patch against Linux kernel 2.6.20,
again. As we promised, some issues are fixed in the latest release with
the help from lkml.
The blackfin-arch patch is at
https://blackfin.uclinux.org/gf/download/frsrelease/25/2490/blackfin-arc
On Mon, 15 Jan 2007 09:37:35 +0100
Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
>
> On Mon, 15 Jan 2007 14:48:57 +1100
> Ben Nizette <[EMAIL PROTECTED]> wrote:
>
>> Remove an unwanted remnant of the recent revert of AVR32/AT91 SPI
patches in -mm. Without this pat
On Mon, 15 Jan 2007 09:37:35 +0100
Haavard Skinnemoen [EMAIL PROTECTED] wrote:
On Mon, 15 Jan 2007 14:48:57 +1100
Ben Nizette [EMAIL PROTECTED] wrote:
Remove an unwanted remnant of the recent revert of AVR32/AT91 SPI
patches in -mm. Without this patch, the AVR32 build of
2.6.20-rc[34]-mm1
Remove an unwanted remnant of the recent revert of AVR32/AT91 SPI
patches in -mm. Without this patch, the AVR32 build of
2.6.20-rc[34]-mm1 breaks.
Signed-off-by: Ben Nizette <[EMAIL PROTECTED]>
---
Index: linux-2.6.20-rc3/arch/avr32/mach-at32ap/at32ap
Remove an unwanted remnant of the recent revert of AVR32/AT91 SPI
patches in -mm. Without this patch, the AVR32 build of
2.6.20-rc[34]-mm1 breaks.
Signed-off-by: Ben Nizette [EMAIL PROTECTED]
---
Index: linux-2.6.20-rc3/arch/avr32/mach-at32ap/at32ap7000.c
Linus Torvalds wrote:
On Thu, 14 Dec 2006, Thomas Gleixner wrote:
The kernel part of the UIO driver also knows how to shut the interrupt
up, so where is the difference ?
Thomas, you've been discussing some totally different and private
Thomas-only thread than everybody else in this
linux-os (Dick Johnson) wrote:
On Wed, 13 Dec 2006, Greg KH wrote:
If anyone has any questions on how to use this interface, or anything
else about it, please let me and Thomas know.
thanks,
greg k-h
[snip]
There are well thought-out methods of creating hardware interfaces that
> have a
linux-os (Dick Johnson) wrote:
On Wed, 13 Dec 2006, Greg KH wrote:
If anyone has any questions on how to use this interface, or anything
else about it, please let me and Thomas know.
thanks,
greg k-h
[snip]
There are well thought-out methods of creating hardware interfaces that
have a
Linus Torvalds wrote:
On Thu, 14 Dec 2006, Thomas Gleixner wrote:
The kernel part of the UIO driver also knows how to shut the interrupt
up, so where is the difference ?
Thomas, you've been discussing some totally different and private
Thomas-only thread than everybody else in this
Greg KH wrote:
But in order to get this core into the kernel tree, we need to have some
"real" drivers written that use it. So, for anyone that wants to see
this go into the tree, now is the time to step forward and post your
patches for hardware that this kind of driver interface is needed.
Greg KH wrote:
But in order to get this core into the kernel tree, we need to have some
real drivers written that use it. So, for anyone that wants to see
this go into the tree, now is the time to step forward and post your
patches for hardware that this kind of driver interface is needed.
Oliver Neukum wrote:
Am Samstag, 9. Dezember 2006 07:11 schrieb Ben Nizette:
Also, you mentioned that the corruption occurs systematically on certain
byte patterns. Therefore it's certainly not related to the cables.
It'd guess that too, but who can that say for sure. :-|
You may have a bit
Oliver Neukum wrote:
Am Samstag, 9. Dezember 2006 07:11 schrieb Ben Nizette:
Also, you mentioned that the corruption occurs systematically on certain
byte patterns. Therefore it's certainly not related to the cables.
It'd guess that too, but who can that say for sure. :-|
You may have a bit
Also, you mentioned that the corruption occurs systematically on certain
byte patterns. Therefore it's certainly not related to the cables.
It'd guess that too, but who can that say for sure. :-|
You may have a bit pattern that stresses the controllers and suddenly
a marginal cable may matter.
Also, you mentioned that the corruption occurs systematically on certain
byte patterns. Therefore it's certainly not related to the cables.
It'd guess that too, but who can that say for sure. :-|
You may have a bit pattern that stresses the controllers and suddenly
a marginal cable may matter.
Jesper Juhl wrote:
Hi,
here's a small patch which
- adds a few archs to the current list of supported platforms.
- adds a few missing slashes at the end of URLs.
- adds a few references to additional documentation.
- adds "make config" to the list of possible configuration targets.
-
Jesper Juhl wrote:
Hi,
here's a small patch which
- adds a few archs to the current list of supported platforms.
- adds a few missing slashes at the end of URLs.
- adds a few references to additional documentation.
- adds make config to the list of possible configuration targets.
-
48 matches
Mail list logo
