Re: [RFC] remove support for AVR32 architecture

On Wed, Mar 1, 2017 at 12:44 PM, Hans-Christian Noren Egtvedt wrote: > I have prepared three patches in my for-linus branch in git tree > https://git.kernel.org/cgit/linux/kernel/git/egtvedt/linux-avr32.git Acked-by: Haavard Skinnemoen Thank you for

Re: [RFC] remove support for AVR32 architecture

On Wed, Mar 1, 2017 at 12:44 PM, Hans-Christian Noren Egtvedt wrote: > I have prepared three patches in my for-linus branch in git tree > https://git.kernel.org/cgit/linux/kernel/git/egtvedt/linux-avr32.git Acked-by: Haavard Skinnemoen Thank you for keeping it alive for so long! I looked

Re: [PATCH v2 1/3] mtd: nand: Cleanup/rework the atmel_nand driver

On Tue, Feb 21, 2017 at 9:14 AM, Alexandre Belloni wrote: > On 21/02/2017 at 18:43:35 +0200, Andy Shevchenko wrote: >> >> Come on, v4.10 has just been release and >> >> It doesn't build anymore. And current case even worse >> Face it. It's dead. >> > > I

Re: [PATCH v2 1/3] mtd: nand: Cleanup/rework the atmel_nand driver

On Tue, Feb 21, 2017 at 9:14 AM, Alexandre Belloni wrote: > On 21/02/2017 at 18:43:35 +0200, Andy Shevchenko wrote: >> >> Come on, v4.10 has just been release and >> >> It doesn't build anymore. And current case even worse >> Face it. It's dead. >> > > I agree it hasn't seen any significant

Re: [PATCH] avr32: fix 'undefined reference to `___copy_from_user'

On Sat, Sep 17, 2016 at 7:56 AM, Guenter Roeck wrote: > avr32 builds fail with: > > arch/avr32/kernel/built-in.o: In function `arch_ptrace': > (.text+0x650): undefined reference to `___copy_from_user' > arch/avr32/kernel/built-in.o:(___ksymtab+___copy_from_user+0x0): undefined

Re: [PATCH] avr32: fix 'undefined reference to `___copy_from_user'

On Sat, Sep 17, 2016 at 7:56 AM, Guenter Roeck wrote: > avr32 builds fail with: > > arch/avr32/kernel/built-in.o: In function `arch_ptrace': > (.text+0x650): undefined reference to `___copy_from_user' > arch/avr32/kernel/built-in.o:(___ksymtab+___copy_from_user+0x0): undefined > reference to

Re: [PATCH] arch: avr32: add dummy syscalls

On Mon, Feb 4, 2013 at 7:39 AM, Al Viro wrote: > On Sun, Feb 03, 2013 at 09:35:39PM -0800, H?vard Skinnemoen wrote: >> >> > But yes, 32bit/32bit/64bit/32bit is another interesting case - >> > fanotify_mark is 32/32/64/32/32. From what ABI says it would seem to >> > be r12/r11/r8:r9/r10/stack,

Re: [PATCH] arch: avr32: add dummy syscalls

On Mon, Feb 4, 2013 at 7:39 AM, Al Viro v...@zeniv.linux.org.uk wrote: On Sun, Feb 03, 2013 at 09:35:39PM -0800, H?vard Skinnemoen wrote: But yes, 32bit/32bit/64bit/32bit is another interesting case - fanotify_mark is 32/32/64/32/32. From what ABI says it would seem to be

Re: [PATCH] arch: avr32: add dummy syscalls

On Sun, Feb 3, 2013 at 9:05 PM, Al Viro wrote: > On Sun, Feb 03, 2013 at 08:52:18PM -0800, H?vard Skinnemoen wrote: > >> You're right on -- in this case, the compiler will skip r10, and do >> (r12, r11, r8:r9, stack). We pass the syscall number in r8, but we >> also unconditionally move r7 to r8

Re: [PATCH] arch: avr32: add dummy syscalls

On Sun, Feb 3, 2013 at 7:02 PM, Al Viro wrote: > On Mon, Feb 04, 2013 at 01:31:11AM +, Al Viro wrote: > >> Unless I'm misreading ocavr32.pdf, that should be (R12, R10:R11, R9, R8) and >> (R12, R10:R11, R9:R8, stack) resp., so fadvise64 doesn't need a wrapper, but >> fadvise64_64 does. And

Re: [PATCH] arch: avr32: add dummy syscalls

On Sun, Feb 3, 2013 at 7:02 PM, Al Viro v...@zeniv.linux.org.uk wrote: On Mon, Feb 04, 2013 at 01:31:11AM +, Al Viro wrote: Unless I'm misreading ocavr32.pdf, that should be (R12, R10:R11, R9, R8) and (R12, R10:R11, R9:R8, stack) resp., so fadvise64 doesn't need a wrapper, but

Re: [PATCH] arch: avr32: add dummy syscalls

On Sun, Feb 3, 2013 at 9:05 PM, Al Viro v...@zeniv.linux.org.uk wrote: On Sun, Feb 03, 2013 at 08:52:18PM -0800, H?vard Skinnemoen wrote: You're right on -- in this case, the compiler will skip r10, and do (r12, r11, r8:r9, stack). We pass the syscall number in r8, but we also unconditionally

Re: [PATCH] arch: avr32: add dummy syscalls

On Sun, Jan 27, 2013 at 7:50 PM, Matthias Brugger wrote: > This patch adds dummy syscalls so that compiling > for this architecture does not provoke warnings when > checksyscalls.sh is called. Nice, but... > --- a/arch/avr32/kernel/syscall_table.S > +++ b/arch/avr32/kernel/syscall_table.S > @@

Re: [PATCH] arch: avr32: add dummy syscalls

On Sun, Jan 27, 2013 at 7:50 PM, Matthias Brugger matthias@gmail.com wrote: This patch adds dummy syscalls so that compiling for this architecture does not provoke warnings when checksyscalls.sh is called. Nice, but... --- a/arch/avr32/kernel/syscall_table.S +++

Re: [PATCH v3 06/10] net/macb: clean up ring buffer logic

On Tue, Oct 30, 2012 at 4:12 AM, David Laight wrote: >> Instead of masking head and tail every time we increment them, just let them >> wrap through UINT_MAX and mask them when subscripting. Add simple accessor >> functions to do the subscripting properly to minimize the chances of messing >>

Re: [PATCH v3 06/10] net/macb: clean up ring buffer logic

On Tue, Oct 30, 2012 at 4:12 AM, David Laight david.lai...@aculab.com wrote: Instead of masking head and tail every time we increment them, just let them wrap through UINT_MAX and mask them when subscripting. Add simple accessor functions to do the subscripting properly to minimize the chances

Re: [PATCH] avr32: fix build error in atstk1006_defconfig

On Tue, Oct 16, 2012 at 12:19 AM, Josh Wu wrote: > fixed the following compile error when use avr32 atstk1006_defconfig: > drivers/mtd/nand/atmel_nand.c: In function 'pmecc_err_location': > drivers/mtd/nand/atmel_nand.c:639: error: implicit declaration of function > 'writel_relaxed' > >

Re: [PATCH] avr32: fix build error in atstk1006_defconfig

On Tue, Oct 16, 2012 at 12:19 AM, Josh Wu josh...@atmel.com wrote: fixed the following compile error when use avr32 atstk1006_defconfig: drivers/mtd/nand/atmel_nand.c: In function 'pmecc_err_location': drivers/mtd/nand/atmel_nand.c:639: error: implicit declaration of function

Re: [GIT PULL] Disintegrate UAPI for avr32

Hi David, On Thu, Oct 4, 2012 at 12:51 PM, David Howells wrote: > Can you merge the following branch into the avr32 tree please. I don't really have an avr32 tree anymore. Can you ask Linus to pull this directly? Havard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel"

Re: [GIT PULL] Disintegrate UAPI for avr32

Hi David, On Thu, Oct 4, 2012 at 12:51 PM, David Howells dhowe...@redhat.com wrote: Can you merge the following branch into the avr32 tree please. I don't really have an avr32 tree anymore. Can you ask Linus to pull this directly? Havard -- To unsubscribe from this list: send the line

Re: the Linux kernel, testsuites, and maybe *you*

On 9/2/07, Andi Kleen <[EMAIL PROTECTED]> wrote: > The other issue to test some of them properly you need unmapped pages > etc. That gets much easier to do in user space. There are some other > issues. vmalloc, vmap, etc. always put a guard page after the allocation. So if you test string

Re: the Linux kernel, testsuites, and maybe *you*

On 9/2/07, Andi Kleen [EMAIL PROTECTED] wrote: The other issue to test some of them properly you need unmapped pages etc. That gets much easier to do in user space. There are some other issues. vmalloc, vmap, etc. always put a guard page after the allocation. So if you test string operations

Re: [patch 09/10] Remove the SLOB allocator for 2.6.23

On 7/10/07, Nick Piggin <[EMAIL PROTECTED]> wrote: Håvard Skinnemoen wrote: > On 7/10/07, Matt Mackall <[EMAIL PROTECTED]> wrote: > >> The only remaining known bug is arguably a problem in nommu that SLOB >> shouldn't be papering over. > > > I'v

Re: [patch 09/10] Remove the SLOB allocator for 2.6.23

On 7/10/07, Matt Mackall <[EMAIL PROTECTED]> wrote: The only remaining known bug is arguably a problem in nommu that SLOB shouldn't be papering over. I've got another one for you: SLOB ignores ARCH_KMALLOC_MINALIGN so using SLOB in combination with DMA and non-coherent architectures causes

Re: [patch 09/10] Remove the SLOB allocator for 2.6.23

On 7/10/07, Matt Mackall [EMAIL PROTECTED] wrote: The only remaining known bug is arguably a problem in nommu that SLOB shouldn't be papering over. I've got another one for you: SLOB ignores ARCH_KMALLOC_MINALIGN so using SLOB in combination with DMA and non-coherent architectures causes data

Re: [patch 09/10] Remove the SLOB allocator for 2.6.23

On 7/10/07, Nick Piggin [EMAIL PROTECTED] wrote: Håvard Skinnemoen wrote: On 7/10/07, Matt Mackall [EMAIL PROTECTED] wrote: The only remaining known bug is arguably a problem in nommu that SLOB shouldn't be papering over. I've got another one for you: SLOB ignores ARCH_KMALLOC_MINALIGN so

Re: kernel BUG at mm/slub.c:3689!

On 6/11/07, Christoph Lameter <[EMAIL PROTECTED]> wrote: Trouble is that ARCH_KMALLOC_MINALIGN is in bytes whereas we would need a shift value for KMALLOC_MIN_SHIFT. Ah, of course. Hrm...I just thought I had an idea, but it wouldn't work... Does the latest patch work? I'm sorry, but I

Re: kernel BUG at mm/slub.c:3689!

On 6/11/07, Christoph Lameter <[EMAIL PROTECTED]> wrote: On Mon, 11 Jun 2007, Håvard Skinnemoen wrote: > I think it's best to ensure that memory returned by kmalloc() actually > can be used for DMA. I used to work around this problem in the SPI > controller driver by using a tempo

Re: kernel BUG at mm/slub.c:3689!

On 6/11/07, Christoph Lameter <[EMAIL PROTECTED]> wrote: On Mon, 11 Jun 2007, Håvard Skinnemoen wrote: > > Note that I do not get why you would be aligning the objects to 32 bytes. > > Increasing the smallest cache size wastes a lot of memory. And it is > > usually

Re: kernel BUG at mm/slub.c:3689!

On 6/11/07, Christoph Lameter <[EMAIL PROTECTED]> wrote: Ok. Drop the patch and use this one instead. This one avoids the use of smaller slabs that cause the conflict. The first slab will be sized 32 bytes instead of 8. Thanks, I'll test it tomorrow. Note that I do not get why you would be

Re: kernel BUG at mm/slub.c:3689!

On 6/11/07, Christoph Lameter <[EMAIL PROTECTED]> wrote: Ahhh... I see its the same phenomenon as before but triggered by a different cause. If you set the align to 32 then the first kmalloc slabs of size 8 16 32 are all of the same size which leads to duplicate files in sysfs. Yes, that

Re: kernel BUG at mm/slub.c:3689!

On 6/11/07, Christoph Lameter <[EMAIL PROTECTED]> wrote: On Mon, 11 Jun 2007, Haavard Skinnemoen wrote: > While trying to get SLUB debugging to not break DMA on AVR32, I ran > into this: This is a known bug in 2.6.22-rc2/rc3. Which version are you running? 2.6.22-rc4. I did a pull from

Re: kernel BUG at mm/slub.c:3689!

On 6/11/07, Paul Mundt <[EMAIL PROTECTED]> wrote: On Mon, Jun 11, 2007 at 04:19:26PM +0200, Haavard Skinnemoen wrote: > I think the combination that triggered this bug was: > * CONFIG_SLUB_DEBUG=y > * ARCH_KMALLOC_MINALIGN=32 > * slub_debug not set at the command line >

Re: kernel BUG at mm/slub.c:3689!

On 6/11/07, Paul Mundt [EMAIL PROTECTED] wrote: On Mon, Jun 11, 2007 at 04:19:26PM +0200, Haavard Skinnemoen wrote: I think the combination that triggered this bug was: * CONFIG_SLUB_DEBUG=y * ARCH_KMALLOC_MINALIGN=32 * slub_debug not set at the command line ARCH_KMALLOC_MINALIGN and

Re: kernel BUG at mm/slub.c:3689!

On 6/11/07, Christoph Lameter [EMAIL PROTECTED] wrote: On Mon, 11 Jun 2007, Haavard Skinnemoen wrote: While trying to get SLUB debugging to not break DMA on AVR32, I ran into this: This is a known bug in 2.6.22-rc2/rc3. Which version are you running? 2.6.22-rc4. I did a pull from Linus'

Re: kernel BUG at mm/slub.c:3689!

On 6/11/07, Christoph Lameter [EMAIL PROTECTED] wrote: Ahhh... I see its the same phenomenon as before but triggered by a different cause. If you set the align to 32 then the first kmalloc slabs of size 8 16 32 are all of the same size which leads to duplicate files in sysfs. Yes, that

Re: kernel BUG at mm/slub.c:3689!

On 6/11/07, Christoph Lameter [EMAIL PROTECTED] wrote: Ok. Drop the patch and use this one instead. This one avoids the use of smaller slabs that cause the conflict. The first slab will be sized 32 bytes instead of 8. Thanks, I'll test it tomorrow. Note that I do not get why you would be

Re: kernel BUG at mm/slub.c:3689!

On 6/11/07, Christoph Lameter [EMAIL PROTECTED] wrote: On Mon, 11 Jun 2007, Håvard Skinnemoen wrote: Note that I do not get why you would be aligning the objects to 32 bytes. Increasing the smallest cache size wastes a lot of memory. And it is usually advantageous if multiple related

Re: kernel BUG at mm/slub.c:3689!

On 6/11/07, Christoph Lameter [EMAIL PROTECTED] wrote: On Mon, 11 Jun 2007, Håvard Skinnemoen wrote: I think it's best to ensure that memory returned by kmalloc() actually can be used for DMA. I used to work around this problem in the SPI controller driver by using a temporary DMA buffer when

Re: kernel BUG at mm/slub.c:3689!

On 6/11/07, Christoph Lameter [EMAIL PROTECTED] wrote: Trouble is that ARCH_KMALLOC_MINALIGN is in bytes whereas we would need a shift value for KMALLOC_MIN_SHIFT. Ah, of course. Hrm...I just thought I had an idea, but it wouldn't work... Does the latest patch work? I'm sorry, but I

Re: [PATCH] atmel_spi: Pass correct DMA address to controller

On 5/16/07, David Brownell <[EMAIL PROTECTED]> wrote: On Wednesday 16 May 2007, Haavard Skinnemoen wrote: > - tx_dma = xfer->tx_dma; > - rx_dma = xfer->rx_dma; > + tx_dma = xfer->tx_dma + xfer->len - len; > + rx_dma = xfer->rx_dma + xfer->len - len; > > /* use scratch

Re: [PATCH] atmel_spi: Pass correct DMA address to controller

On 5/16/07, David Brownell [EMAIL PROTECTED] wrote: On Wednesday 16 May 2007, Haavard Skinnemoen wrote: - tx_dma = xfer-tx_dma; - rx_dma = xfer-rx_dma; + tx_dma = xfer-tx_dma + xfer-len - len; + rx_dma = xfer-rx_dma + xfer-len - len; /* use scratch buffer only when rx

Re: missing kretprobes support on avr32 and sparc64

On Sat, March 31, 2007 15:15, Christoph Hellwig wrote: > Currently all avr32 and sparc64 don't support kretprobes unlike all > other kprobes supporting architectures. This is not nice from the > user interface point of view and from the ugly ifdefs point of view. > Is there a reason these ports

Re: missing kretprobes support on avr32 and sparc64

On Sat, March 31, 2007 15:15, Christoph Hellwig wrote: Currently all avr32 and sparc64 don't support kretprobes unlike all other kprobes supporting architectures. This is not nice from the user interface point of view and from the ugly ifdefs point of view. Is there a reason these ports can't

Re: [PATCH] Bitbanging i2c bus driver using the GPIO API

On Fri, March 9, 2007 20:30, David Brownell wrote: > On Friday 09 March 2007 10:48 am, Haavard Skinnemoen wrote: >> This is a very simple bitbanging i2c bus driver utilizing the new >> arch-neutral GPIO API. Useful for chips that don't have a built-in >> i2c controller, additional i2c busses, or

Re: [PATCH] Bitbanging i2c bus driver using the GPIO API

On Fri, March 9, 2007 20:30, David Brownell wrote: On Friday 09 March 2007 10:48 am, Haavard Skinnemoen wrote: This is a very simple bitbanging i2c bus driver utilizing the new arch-neutral GPIO API. Useful for chips that don't have a built-in i2c controller, additional i2c busses, or testing

Re: [patch 2.6.20-rc1 0/6] arch-neutral GPIO calls

On 12/20/06, David Brownell <[EMAIL PROTECTED]> wrote: Based on earlier discussion, I'm sending a refresh of the generic GPIO patch, with several (ARM based) implementations in separate patches: - Core patch, doc + + - OMAP implementation - AT91 implementation - PXA implementation -

Re: [patch 2.6.20-rc1 0/6] arch-neutral GPIO calls

On 12/20/06, David Brownell [EMAIL PROTECTED] wrote: Based on earlier discussion, I'm sending a refresh of the generic GPIO patch, with several (ARM based) implementations in separate patches: - Core patch, doc + asm-arm/gpio.h + asm-generic/gpio.h - OMAP implementation - AT91 implementation