Re: [PATCH 5/9] blackfin: A couple of task-mm handling fixes
On Monday 23 April 2012 03:09:01 Anton Vorontsov wrote: 1. Working with task-mm w/o getting mm or grabing the task lock is dangerous as -mm might disappear (exit_mm() assigns NULL under task_lock(), so tasklist lock is not enough). that isn't a problem for this code as it specifically checks if it's in an atomic section. if it is, then task-mm can't go away on us. We can't use get_task_mm()/mmput() pair as mmput() might sleep, so we have to take the task lock while handle its mm. if we're not in an atomic section, then sleeping is fine. 2. Checking for process-mm is not enough because process' main thread may exit or detach its mm via use_mm(), but other threads may still have a valid mm. i don't think it matters for this code (per the reasons above). To catch this we use find_lock_task_mm(), which walks up all threads and returns an appropriate task (with task lock held). certainly fine for the non-atomic code path. i guess we'll notice in crashes if it causes a problem in atomic code paths as well. -mike signature.asc Description: This is a digitally signed message part. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] atomic: Allow atomic_inc_not_zero to be overridden
On Thursday 01 March 2012 02:09:53 Anton Blanchard wrote: We want to implement a ppc64 specific version of atomic_inc_not_zero so wrap it in an ifdef to allow it to be overridden. Acked-by: Mike Frysinger vap...@gentoo.org -mike signature.asc Description: This is a digitally signed message part. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 ] Implement GET_IP/SET_IP for powerpc architecture.
Acked-by: Mike Frysinger vap...@gentoo.org -mike signature.asc Description: This is a digitally signed message part. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Implement GET_IP/SET_IP for powerpc architecture.
On Thursday 02 February 2012 09:41:25 Srikar Dronamraju wrote: +#define GET_FP(regs) (0) +#define SET_FP(regs, val) ppc doesn't have a standard FP location ? +#define profile_pc(regs) GET_IP(regs) pretty sure you don't need this as asm-generic/ptrace.h already has a definition for you -mike signature.asc Description: This is a digitally signed message part. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Implement GET_IP/SET_IP for powerpc architecture.
On Thursday 02 February 2012 11:36:59 Srikar Dronamraju wrote: * Mike Frysinger vap...@gentoo.org [2012-02-02 11:28:46]: On Thursday 02 February 2012 09:41:25 Srikar Dronamraju wrote: +#define profile_pc(regs) GET_IP(regs) pretty sure you don't need this as asm-generic/ptrace.h already has a definition for you On ppc64, profile_pc is an extern function if CONFIG_SMP is set. else its same as whats defined in asm-generic/ptrace.h the code i quoted was from !CONFIG_SMP -mike signature.asc Description: This is a digitally signed message part. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3] asm-generic/gpio.h: merge basic gpiolib wrappers
Rather than requiring architectures that use gpiolib but don't have any need to define anything custom to copy an asm/gpio.h, merge this code into the asm-generic/gpio.h. We add ifdef checks so that arches can still override things while using the asm-generic/gpio.h, but on a more fine grained per-func approach. I've compile tested these guys (with without GPIOLIB), but don't have the hardware to boot: - alpha defconfig - arm: all defconfigs - blackfin defconfig - ia64 defconfig - m68k: multi m5208evb defconfig - mips: ar7 ath79 bcm47xx bcm63xx ip22 defconfig - powerpc: mpc85xx ppc64 defconfig - sh: kfr2r09 defconfig - sparc defconfig - x86_64 defconfig I don't have any toolchains for avr32, microblaze, openrisc, unicore32, or xtensa. So they lose :x. Signed-off-by: Mike Frysinger vap...@gentoo.org --- v3 - built on top of Linus' recent gpio fixes - fixes builds for one or two arm platforms - all the arm defconfigs have been checked on the disassembly level arch/alpha/include/asm/Kbuild |2 + arch/alpha/include/asm/gpio.h | 55 --- arch/arm/include/asm/gpio.h | 16 -- arch/arm/include/asm/hardware/iop3xx-gpio.h | 21 ++-- arch/arm/mach-davinci/include/mach/gpio.h | 13 ++--- arch/arm/mach-ixp4xx/include/mach/gpio.h|8 +-- arch/arm/mach-ks8695/include/mach/gpio.h|1 + arch/arm/mach-mmp/include/mach/gpio.h |2 - arch/arm/mach-pxa/include/mach/gpio.h |2 +- arch/arm/mach-sa1100/include/mach/gpio.h| 13 ++--- arch/arm/mach-shmobile/include/mach/gpio.h | 16 -- arch/arm/mach-w90x900/include/mach/gpio.h |1 + arch/arm/plat-omap/include/plat/gpio.h |4 +- arch/arm/plat-pxa/include/plat/gpio.h |8 ++-- arch/avr32/mach-at32ap/include/mach/gpio.h | 19 +-- arch/blackfin/include/asm/gpio.h| 16 ++ arch/ia64/include/asm/Kbuild|2 + arch/ia64/include/asm/gpio.h| 55 --- arch/m68k/include/asm/gpio.h|7 +++ arch/microblaze/include/asm/Kbuild |2 + arch/microblaze/include/asm/gpio.h | 53 -- arch/mips/include/asm/mach-ar7/gpio.h |5 -- arch/mips/include/asm/mach-ath79/gpio.h |8 ++- arch/mips/include/asm/mach-bcm47xx/gpio.h |3 + arch/mips/include/asm/mach-bcm63xx/gpio.h |5 -- arch/mips/include/asm/mach-generic/gpio.h |8 +-- arch/mips/include/asm/mach-loongson/gpio.h |7 +-- arch/mips/include/asm/mach-rc32434/gpio.h | 10 +--- arch/mips/include/asm/pmc-sierra/msp71xx/gpio.h | 12 +--- arch/openrisc/include/asm/Kbuild|1 + arch/openrisc/include/asm/gpio.h| 65 --- arch/powerpc/include/asm/Kbuild |2 + arch/powerpc/include/asm/gpio.h | 53 -- arch/sh/include/asm/gpio.h | 32 +--- arch/sparc/include/asm/Kbuild |1 + arch/sparc/include/asm/gpio.h | 36 - arch/unicore32/include/asm/gpio.h |8 ++- arch/x86/include/asm/Kbuild |2 + arch/x86/include/asm/gpio.h | 53 -- arch/xtensa/include/asm/Kbuild |2 + arch/xtensa/include/asm/gpio.h | 56 --- include/asm-generic/gpio.h | 23 42 files changed, 107 insertions(+), 601 deletions(-) delete mode 100644 arch/alpha/include/asm/gpio.h delete mode 100644 arch/ia64/include/asm/gpio.h delete mode 100644 arch/microblaze/include/asm/gpio.h delete mode 100644 arch/openrisc/include/asm/gpio.h delete mode 100644 arch/powerpc/include/asm/gpio.h delete mode 100644 arch/sparc/include/asm/gpio.h delete mode 100644 arch/x86/include/asm/gpio.h delete mode 100644 arch/xtensa/include/asm/gpio.h diff --git a/arch/alpha/include/asm/Kbuild b/arch/alpha/include/asm/Kbuild index e423def..0bcff1a 100644 --- a/arch/alpha/include/asm/Kbuild +++ b/arch/alpha/include/asm/Kbuild @@ -1,5 +1,7 @@ include include/asm-generic/Kbuild.asm +generic-y += gpio.h + header-y += compiler.h header-y += console.h header-y += fpu.h diff --git a/arch/alpha/include/asm/gpio.h b/arch/alpha/include/asm/gpio.h deleted file mode 100644 index 7dc6a63..000 --- a/arch/alpha/include/asm/gpio.h +++ /dev/null @@ -1,55 +0,0 @@ -/* - * Generic GPIO API implementation for Alpha. - * - * A stright copy of that for PowerPC which was: - * - * Copyright (c) 2007-2008 MontaVista Software, Inc. - * - * Author: Anton Vorontsov avoront...@ru.mvista.com - * - * This program is free software; you can
[PATCH] asm-generic/gpio.h: merge basic gpiolib wrappers
Rather than requiring architectures that use gpiolib but don't have
any need to define anything custom to copy an asm/gpio.h, merge this
code into the asm-generic/gpio.h. We add ifdef checks so that arches
can still override things while using the asm-generic/gpio.h, but on
a more fine grained per-func approach.
I've compile tested these guys (with without GPIOLIB), but don't
have the hardware to boot:
- alpha defconfig
- arm defconfig
- blackfin defconfig
- ia64 defconfig
- mips: ar7 ath79 bcm47xx bcm63xx ip22 defconfig
- powerpc: mpc85xx ppc64 defconfig
- sh: kfr2r09 defconfig
- sparc defconfig
- x86_64 defconfig
I don't have any toolchains for avr32, microblaze, openrisc, unicore32,
or xtensa. So they lose :x.
I don't see m68k supporting gpoilib, so I've just ignored it.
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
arch/alpha/include/asm/Kbuild |2 +
arch/alpha/include/asm/gpio.h | 55 ---
arch/arm/include/asm/gpio.h | 13 +++--
arch/avr32/mach-at32ap/include/mach/gpio.h | 19 +--
arch/blackfin/include/asm/gpio.h| 16 ++
arch/ia64/include/asm/Kbuild|2 +
arch/ia64/include/asm/gpio.h| 55 ---
arch/microblaze/include/asm/Kbuild |2 +
arch/microblaze/include/asm/gpio.h | 53 --
arch/mips/include/asm/mach-ar7/gpio.h |5 --
arch/mips/include/asm/mach-ath79/gpio.h |8 ++-
arch/mips/include/asm/mach-bcm47xx/gpio.h |3 +
arch/mips/include/asm/mach-bcm63xx/gpio.h |5 --
arch/mips/include/asm/mach-generic/gpio.h |8 +--
arch/mips/include/asm/mach-loongson/gpio.h |7 +--
arch/mips/include/asm/mach-rc32434/gpio.h | 10 +---
arch/mips/include/asm/pmc-sierra/msp71xx/gpio.h | 12 +---
arch/openrisc/include/asm/Kbuild|1 +
arch/openrisc/include/asm/gpio.h| 65 ---
arch/powerpc/include/asm/Kbuild |2 +
arch/powerpc/include/asm/gpio.h | 53 --
arch/sh/include/asm/gpio.h | 32 +---
arch/sparc/include/asm/Kbuild |1 +
arch/sparc/include/asm/gpio.h | 36 -
arch/unicore32/include/asm/gpio.h |8 ++-
arch/x86/include/asm/Kbuild |2 +
arch/x86/include/asm/gpio.h | 53 --
arch/xtensa/include/asm/Kbuild |2 +
arch/xtensa/include/asm/gpio.h | 56 ---
include/asm-generic/gpio.h | 23
30 files changed, 81 insertions(+), 528 deletions(-)
delete mode 100644 arch/alpha/include/asm/gpio.h
delete mode 100644 arch/ia64/include/asm/gpio.h
delete mode 100644 arch/microblaze/include/asm/gpio.h
delete mode 100644 arch/openrisc/include/asm/gpio.h
delete mode 100644 arch/powerpc/include/asm/gpio.h
delete mode 100644 arch/sparc/include/asm/gpio.h
delete mode 100644 arch/x86/include/asm/gpio.h
delete mode 100644 arch/xtensa/include/asm/gpio.h
diff --git a/arch/alpha/include/asm/Kbuild b/arch/alpha/include/asm/Kbuild
index e423def..0bcff1a 100644
--- a/arch/alpha/include/asm/Kbuild
+++ b/arch/alpha/include/asm/Kbuild
@@ -1,5 +1,7 @@
include include/asm-generic/Kbuild.asm
+generic-y += gpio.h
+
header-y += compiler.h
header-y += console.h
header-y += fpu.h
diff --git a/arch/alpha/include/asm/gpio.h b/arch/alpha/include/asm/gpio.h
deleted file mode 100644
index 7dc6a63..000
--- a/arch/alpha/include/asm/gpio.h
+++ /dev/null
@@ -1,55 +0,0 @@
-/*
- * Generic GPIO API implementation for Alpha.
- *
- * A stright copy of that for PowerPC which was:
- *
- * Copyright (c) 2007-2008 MontaVista Software, Inc.
- *
- * Author: Anton Vorontsov avoront...@ru.mvista.com
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-
-#ifndef _ASM_ALPHA_GPIO_H
-#define _ASM_ALPHA_GPIO_H
-
-#include linux/errno.h
-#include asm-generic/gpio.h
-
-#ifdef CONFIG_GPIOLIB
-
-/*
- * We don't (yet) implement inlined/rapid versions for on-chip gpios.
- * Just call gpiolib.
- */
-static inline int gpio_get_value(unsigned int gpio)
-{
- return __gpio_get_value(gpio);
-}
-
-static inline void gpio_set_value(unsigned int gpio, int value)
-{
- __gpio_set_value(gpio, value);
-}
-
-static inline int gpio_cansleep(unsigned int gpio)
-{
- return __gpio_cansleep(gpio);
-}
-
-static inline int gpio_to_irq(unsigned int gpio)
-{
- return __gpio_to_irq(gpio);
-}
-
-static inline int irq_to_gpio(unsigned
Re: [PATCH] asm-generic/gpio.h: merge basic gpiolib wrappers
On Thu, Oct 27, 2011 at 15:11, Russell King - ARM Linux wrote:
On Thu, Oct 27, 2011 at 09:01:43AM -0400, Mike Frysinger wrote:
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index d494001..622851c 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -170,6 +170,29 @@ extern int __gpio_cansleep(unsigned gpio);
extern int __gpio_to_irq(unsigned gpio);
+#ifndef gpio_get_value
+#define gpio_get_value(gpio) __gpio_get_value(gpio)
+#endif
+
+#ifndef gpio_set_value
+#define gpio_set_value(gpio, value) __gpio_set_value(gpio, value)
+#endif
+
+#ifndef gpio_cansleep
+#define gpio_cansleep(gpio) __gpio_cansleep(gpio)
+#endif
+
+#ifndef gpio_to_irq
+#define gpio_to_irq(gpio) __gpio_to_irq(gpio)
+#endif
+
+#ifndef irq_to_gpio
+static inline int irq_to_gpio(unsigned int irq)
+{
+ return -EINVAL;
+}
+#endif
+
This is extremely dangerous. Consider for example this code
(see ARM mach-davinci's gpio.h):
...
This is why I didn't solve this using the preprocessor method in ARM, but
instead used __ARM_GPIOLIB_COMPLEX to control whether these definitions
are required.
i thought the arm mach were defining things already, but i guess i
missed some in my review
easy enough to glue the arm-specific world to the asm-generic world
... a bit ugly, but should work i think:
#ifndef __ARM_GPIOLIB_COMPLEX
/* assume the mach has defined this */
#ifndef gpio_get_value
#define gpio_get_value gpio_get_value
#endif
#ifndef gpio_set_value
#define gpio_set_value gpio_set_value
#endif
#ifndef gpio_cansleep
#define gpio_cansleep gpio_cansleep
#endif
#ifndef gpio_to_irq
#define gpio_to_irq gpio_to_irq
#endif
#ifndef irq_to_gpio
#define irq_to_gpio irq_to_gpio
#endif
...
the next step might be to drill down into the arm mach's and sprinkle
the defines into the parts that need it ...
-mike
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] asm-generic/gpio.h: merge basic gpiolib wrappers
Rather than requiring architectures that use gpiolib but don't have any need to define anything custom to copy an asm/gpio.h, merge this code into the asm-generic/gpio.h. We add ifdef checks so that arches can still override things while using the asm-generic/gpio.h, but on a more fine grained per-func approach. I've compile tested these guys (with without GPIOLIB), but don't have the hardware to boot: - alpha defconfig - arm: every defconfig - blackfin defconfig - ia64 defconfig - m68k: multi m5208evb defconfig - mips: ar7 ath79 bcm47xx bcm63xx ip22 defconfig - powerpc: mpc85xx ppc64 defconfig - sh: kfr2r09 defconfig - sparc defconfig - x86_64 defconfig There is concern for adding code to the arm gpio headers, but since my diffstat removes more than it adds, and it only adds when there are funcs which need to be customized in the first place, I think this holds to the desire to ultimately kill off (when possible) the misc sub gpio headers. After all, if you can kill the overridden function, my additional lines shouldn't be needed either. I don't have any toolchains for avr32, microblaze, openrisc, unicore32, or xtensa. So they lose :x. Signed-off-by: Mike Frysinger vap...@gentoo.org --- v2 - grub through arm gpio.h headers - add m68k support note: i've done a full build of all arm defconfigs, and any warnings or build failures appear to be unrelated to my change (sadly, there seem to be way more than there should be ...). i'll start a 2nd build which compares the binary output to make sure they're the same, but if people see something that needs more attention before that, feel free to highlight it. arch/alpha/include/asm/Kbuild |2 + arch/alpha/include/asm/gpio.h | 55 --- arch/arm/include/asm/gpio.h | 16 -- arch/arm/include/asm/hardware/iop3xx-gpio.h | 21 ++-- arch/arm/mach-davinci/include/mach/gpio.h | 11 ++-- arch/arm/mach-ixp4xx/include/mach/gpio.h|8 +-- arch/arm/mach-ks8695/include/mach/gpio.h|1 + arch/arm/mach-mmp/include/mach/gpio.h |2 - arch/arm/mach-pxa/include/mach/gpio.h |2 +- arch/arm/mach-sa1100/include/mach/gpio.h| 13 ++--- arch/arm/mach-shmobile/include/mach/gpio.h | 16 -- arch/arm/mach-w90x900/include/mach/gpio.h |1 + arch/arm/plat-mxc/include/mach/irqs.h |2 - arch/arm/plat-omap/include/plat/gpio.h |4 +- arch/arm/plat-pxa/include/plat/gpio.h |6 +-- arch/avr32/mach-at32ap/include/mach/gpio.h | 19 +-- arch/blackfin/include/asm/gpio.h| 16 ++ arch/ia64/include/asm/Kbuild|2 + arch/ia64/include/asm/gpio.h| 55 --- arch/m68k/include/asm/gpio.h|7 +++ arch/microblaze/include/asm/Kbuild |2 + arch/microblaze/include/asm/gpio.h | 53 -- arch/mips/include/asm/mach-ar7/gpio.h |5 -- arch/mips/include/asm/mach-ath79/gpio.h |8 ++- arch/mips/include/asm/mach-bcm47xx/gpio.h |3 + arch/mips/include/asm/mach-bcm63xx/gpio.h |5 -- arch/mips/include/asm/mach-generic/gpio.h |8 +-- arch/mips/include/asm/mach-loongson/gpio.h |7 +-- arch/mips/include/asm/mach-rc32434/gpio.h | 10 +--- arch/mips/include/asm/pmc-sierra/msp71xx/gpio.h | 12 +--- arch/openrisc/include/asm/Kbuild|1 + arch/openrisc/include/asm/gpio.h| 65 --- arch/powerpc/include/asm/Kbuild |2 + arch/powerpc/include/asm/gpio.h | 53 -- arch/sh/include/asm/gpio.h | 32 +--- arch/sparc/include/asm/Kbuild |1 + arch/sparc/include/asm/gpio.h | 36 - arch/unicore32/include/asm/gpio.h |8 ++- arch/x86/include/asm/Kbuild |2 + arch/x86/include/asm/gpio.h | 53 -- arch/xtensa/include/asm/Kbuild |2 + arch/xtensa/include/asm/gpio.h | 56 --- include/asm-generic/gpio.h | 23 43 files changed, 105 insertions(+), 601 deletions(-) delete mode 100644 arch/alpha/include/asm/gpio.h delete mode 100644 arch/ia64/include/asm/gpio.h delete mode 100644 arch/microblaze/include/asm/gpio.h delete mode 100644 arch/openrisc/include/asm/gpio.h delete mode 100644 arch/powerpc/include/asm/gpio.h delete mode 100644 arch/sparc/include/asm/gpio.h delete mode 100644 arch/x86/include/asm/gpio.h delete mode 100644 arch/xtensa/include/asm/gpio.h diff --git a/arch/alpha/include/asm/Kbuild b
Re: [PATCH] mtd: m25p80: add EON flash EN25Q32B into spi flash id table
Acked-by: Mike Frysinger vap...@gentoo.org -mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC/PATCH] mm/futex: Fix futex writes on archs with SW tracking of dirty young
On Wed, Jul 27, 2011 at 06:17, Peter Zijlstra wrote: On Wed, 2011-07-27 at 11:09 +0100, David Howells wrote: Can you inline this for the NOMMU case please? --- Subject: mm: Fix fixup_user_fault() for MMU=n In commit 2efaca927 (mm/futex: fix futex writes on archs with SW tracking of dirty young) we forgot about MMU=n. This patch fixes that. can we get this merged ? mainline is now broken, linux-next is still broken, and it seems gregkh is pulling this into the stable 3.0.1 which means that's going to be broken too. -mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC/PATCH] mm/futex: Fix futex writes on archs with SW tracking of dirty young
On Mon, Jul 18, 2011 at 21:29, Benjamin Herrenschmidt wrote: The futex code currently attempts to write to user memory within a pagefault disabled section, and if that fails, tries to fix it up using get_user_pages(). This doesn't work on archs where the dirty and young bits are maintained by software, since they will gate access permission in the TLB, and will not be updated by gup(). In addition, there's an expectation on some archs that a spurious write fault triggers a local TLB flush, and that is missing from the picture as well. I decided that adding those features to gup() would be too much for this already too complex function, and instead added a new simpler fixup_user_fault() which is essentially a wrapper around handle_mm_fault() which the futex code can call. unfortunately, this breaks all nommu ports. you added fixup_user_fault() to mm/memory.c only which is not used by nommu logic. -mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC/PATCH] mm/futex: Fix futex writes on archs with SW tracking of dirty young
On Wed, Jul 27, 2011 at 03:20, Benjamin Herrenschmidt wrote: Hoping the BUG() isn't trippable by userspace but then it's no mmu, it's not like we care what userspace can do right :-) side note ... common misconception that no mmu == no memory protection. a few of the nommu processors have memory protection, just no virtual-physical translation. thanks for the patch ! -mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] driver core: Add ability for arch code to setup pdev_archdata
On Wed, Jun 22, 2011 at 08:02, Kumar Gala wrote:
--- /dev/null
+++ b/include/asm-generic/platform_device.h
@@ -0,0 +1,11 @@
missing header blob with explanation/copyright/license
+/*
+ * an architecture can override to define arch_setup_pdev_archdata
+ */
+#ifndef arch_setup_pdev_archdata
+static inline void arch_setup_pdev_archdata(struct platform_device *pdev) { }
+#endif
missing explanation of what the func actually does, and this header
lacks a forward struct decl for platform_device
-mike
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Fix build warning of the defconfigs
On Wed, Jun 1, 2011 at 12:29, Wanlong Gao wrote: arch/blackfin/configs/CM-BF548_defconfig | 2 +- Acked-by: Mike Frysinger vap...@gentoo.org -mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] atomic: add *_dec_not_zero
On Sun, May 8, 2011 at 05:33, Sven Eckelmann wrote: Russell King - ARM Linux wrote: [...] Do we need atomic_dec_not_zero() et.al. in every arch header - is there no generic header which it could be added to? Mike Frysinger already tried to answer it in banlktimctgbto3dsnj3d3r7nggs0kf9...@mail.gmail.com: that's what asm-generic is for. if the arch isnt using it, it's either because the arch needs to convert to it, or they're using SMP and asm-generic doesnt yet support that for atomic.h. for example, the Blackfin port only needed updating for the SMP case. in the non-SMP case, we're getting the def from asm-generic/atomic.h. Feel free to change that but I just followed the style used by all other macros and will not redesign the complete atomic*.h idea. what you're doing is currently correct. i think merging SMP support into asm-generic for atomic* will take a bit of pondering first. -mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] lib: Consolidate DEBUG_STACK_USAGE option
On Sat, May 7, 2011 at 01:57, Stephen Boyd wrote: Most arches define CONFIG_DEBUG_STACK_USAGE exactly the same way. Move it to lib/Kconfig.debug so each arch doesn't have to define it. This obviously makes the option generic, but that's fine because the config is already used in generic code. It's not obvious to me that sysrq-P actually does anything different with this option enabled, but I erred on the side of caution by keeping the most inclusive wording. Cc: uclinux-dist-de...@blackfin.uclinux.org arch/blackfin/Kconfig.debug | 9 - Acked-by: Mike Frysinger vap...@gentoo.org -mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] atomic: add *_dec_not_zero
On Wed, May 4, 2011 at 04:05, David Laight wrote: Introduce an *_dec_not_zero operation. Make this a special case of *_add_unless because batman-adv uses atomic_dec_not_zero in different places like re-broadcast queue or aggregation queue management. There are other non-final patches which may also want to use this macro. Isn't there a place where a default definition of this can be defined? Instead of adding it separately to every architecture. that's what asm-generic is for. if the arch isnt using it, it's either because the arch needs to convert to it, or they're using SMP and asm-generic doesnt yet support that for atomic.h. for example, the Blackfin port only needed updating for the SMP case. in the non-SMP case, we're getting the def from asm-generic/atomic.h. -mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] atomic: add *_dec_not_zero
On Tue, May 3, 2011 at 17:30, Sven Eckelmann wrote: Introduce an *_dec_not_zero operation. Make this a special case of *_add_unless because batman-adv uses atomic_dec_not_zero in different places like re-broadcast queue or aggregation queue management. There are other non-final patches which may also want to use this macro. Cc: uclinux-dist-de...@blackfin.uclinux.org --- a/arch/blackfin/include/asm/atomic.h +++ b/arch/blackfin/include/asm/atomic.h @@ -103,6 +103,7 @@ static inline int atomic_test_mask(int mask, atomic_t *v) c != (u); \ }) #define atomic_inc_not_zero(v) atomic_add_unless((v), 1, 0) +#define atomic_dec_not_zero(v) atomic_add_unless((v), -1, 0) /* * atomic_inc_and_test - increment and test no opinion on the actual idea, but for the Blackfin pieces: Acked-by: Mike Frysinger vap...@gentoo.org -mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 9/14] PM / Blackfin: Use struct syscore_ops instead of sysdevs for PM
On Sun, Apr 17, 2011 at 17:11, Rafael J. Wysocki wrote:
Convert some Blackfin architecture's code to using struct syscore_ops
objects for power management instead of sysdev classes and sysdevs.
This simplifies the code and reduces the kernel's memory footprint.
It also is necessary for removing sysdevs from the kernel entirely in
the future.
looks straight forward enough ...
Acked-by: Mike Frysinger vap...@gentoo.org
+static struct syscore_ops nmi_syscore_ops = {
.resume = nmi_wdt_resume,
.suspend = nmi_wdt_suspend,
};
a bit sad this couldnt be made const
-mike
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] drivers: char: hvc: add arm JTAG DCC console support
On Thu, Apr 7, 2011 at 14:39, RONETIX - Asen Dimov wrote: On 11/30/2010 09:25 PM, Daniel Walker wrote: This driver adds a basic console that uses the arm JTAG DCC to transfer data back and forth. It has support for ARMv6 and ARMv7. This console is created under the HVC driver, and should be named /dev/hvcX (or /dev/hvc0 for example). drivers/char/Kconfig | 9 +++ drivers/char/Makefile | 1 + drivers/char/hvc_dcc.c | 133 ... this DCC driver implements one channel, but what about implementing multiple channels. For example reserve few(3) bits for channel number, and two bits for carried data, then fill the rest bytes with with some data and send the word(32 bits) over DCC. On the Linux side writing on /dev/hvcX puts the number X as channel number, and on the other side the CPU emulator gets the data and redistribute it to TCP/IP socket. I have started write some code implementing this. Are there any one interested in this multiple channels, and are there any one started to work on it? this sort of multiplexing of the data stream sounds like the job for userspace ? or maybe a line discipline ? inserting structured data into the kernel driver doesnt sound right to me ... -mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [uclinux-dist-devel] [PATCH] sched: provide scheduler_ipi() callback in response to smp_send_reschedule()
On Mon, Jan 17, 2011 at 06:07, Peter Zijlstra wrote: Also, while reading through all this, I noticed the blackfin SMP code looks to be broken, it simply discards any IPI when low on memory. not really. see changelog of commit 73a400646b8e26615f3ef1a0a4bc0cd0d5bd284c. -mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/9] Typo fixes of faild to failed
On Fri, Oct 22, 2010 at 01:17, Joe Perches wrote: drivers/ata/pata_bf54x.c | 2 +- drivers/video/bf54x-lq043fb.c | 6 +++--- drivers/video/bfin-t350mcqb-fb.c | 2 +- Acked-by: Mike Frysinger vap...@gentoo.org -mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] mtd: m25p80: Fix false-positive probing
On Tue, Jun 22, 2010 at 12:57, Anton Vorontsov wrote: Since commit 18c6182bae0acca220ed6611f741034d563cd19f (Rework probing/JEDEC code), m25p80 driver successfully registers chips even if JEDEC probing fails. This was needed to support non-JEDEC flashes. Though, it appears that some platforms (e.g. blackfin bf533 stamp[1]) used the old behavior to detect if there's any flash connected, so the driver have to fail on JEDEC probing errors. This patch restores the old behavior for JEDEC flashes, and adds -nonjedec SPI device IDs for M25Pxx flashes, so that the kernel still supports non-JEDEC flashes. Acked-by: Mike Frysinger vap...@gentoo.org [1] http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdittracker_item_id=5975 http://blackfin.uclinux.org/gf/tracker/5975 Reported-by: Mingquan Pan grace@analog.com -mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
On Mon, Jun 21, 2010 at 07:20, Anton Vorontsov wrote:
You can't easily change OF. It's like let's change ACPI tables
or BIOS in these PCs. Doable, but involves things like reflashing.
And we usually have to support old BIOSes as well.
OTOH, I see (git grep m25p arch/powerpc/boot/dts/) that in
mainline kernel only MPC8569 board has a correct m25p
node, and it is STMicro variant (it is JEDEC capable).
As we don't really have to support out of tree code, I'd
just go with this patch, assuming that we have to change
device tree for boards with non-JEDEC flashes. It's
effectively the same thing as platform data flag, except
that it works automatically for OF platforms.
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 81e49a9..a610ca9 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -680,6 +680,16 @@ static const struct spi_device_id m25p_ids[] = {
{ m25p64, INFO(0x202017, 0, 64 * 1024, 128, 0) },
{ m25p128, INFO(0x202018, 0, 256 * 1024, 64, 0) },
+ { m25p05-nonjedec, INFO(0, 0, 32 * 1024, 2, 0) },
+ { m25p10-nonjedec, INFO(0, 0, 32 * 1024, 4, 0) },
+ { m25p20-nonjedec, INFO(0, 0, 64 * 1024, 4, 0) },
+ { m25p40-nonjedec, INFO(0, 0, 64 * 1024, 8, 0) },
+ { m25p80-nonjedec, INFO(0, 0, 64 * 1024, 16, 0) },
+ { m25p16-nonjedec, INFO(0, 0, 64 * 1024, 32, 0) },
+ { m25p32-nonjedec, INFO(0, 0, 64 * 1024, 64, 0) },
+ { m25p64-nonjedec, INFO(0, 0, 64 * 1024, 128, 0) },
+ { m25p128-nonjedec, INFO(0, 0, 256 * 1024, 64, 0) },
+
are you picking the m25p because its flash geometry matches whatever
you're using, or because you have some weird variant of the m25p that
has JEDEC commands removed ?
-mike
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
On Mon, Jun 21, 2010 at 12:47, Anton Vorontsov wrote:
On Mon, Jun 21, 2010 at 12:34:05PM -0400, Mike Frysinger wrote:
On Mon, Jun 21, 2010 at 07:20, Anton Vorontsov wrote:
You can't easily change OF. It's like let's change ACPI tables
or BIOS in these PCs. Doable, but involves things like reflashing.
And we usually have to support old BIOSes as well.
OTOH, I see (git grep m25p arch/powerpc/boot/dts/) that in
mainline kernel only MPC8569 board has a correct m25p
node, and it is STMicro variant (it is JEDEC capable).
As we don't really have to support out of tree code, I'd
just go with this patch, assuming that we have to change
device tree for boards with non-JEDEC flashes. It's
effectively the same thing as platform data flag, except
that it works automatically for OF platforms.
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 81e49a9..a610ca9 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -680,6 +680,16 @@ static const struct spi_device_id m25p_ids[] = {
{ m25p64, INFO(0x202017, 0, 64 * 1024, 128, 0) },
{ m25p128, INFO(0x202018, 0, 256 * 1024, 64, 0) },
+ { m25p05-nonjedec, INFO(0, 0, 32 * 1024, 2, 0) },
+ { m25p10-nonjedec, INFO(0, 0, 32 * 1024, 4, 0) },
+ { m25p20-nonjedec, INFO(0, 0, 64 * 1024, 4, 0) },
+ { m25p40-nonjedec, INFO(0, 0, 64 * 1024, 8, 0) },
+ { m25p80-nonjedec, INFO(0, 0, 64 * 1024, 16, 0) },
+ { m25p16-nonjedec, INFO(0, 0, 64 * 1024, 32, 0) },
+ { m25p32-nonjedec, INFO(0, 0, 64 * 1024, 64, 0) },
+ { m25p64-nonjedec, INFO(0, 0, 64 * 1024, 128, 0) },
+ { m25p128-nonjedec, INFO(0, 0, 256 * 1024, 64, 0) },
+
are you picking the m25p because its flash geometry matches whatever
you're using, or because you have some weird variant of the m25p that
has JEDEC commands removed ?
The latter. It's Numonyx M25Pxx flashes, see
http://www.numonyx.com/Documents/Datasheets/M25P80.pdf
The RDID instruction is available only for parts made with 110
nm Technology identified with Process letter '4'.
lovely. i guess this patch is the way to go to satisfy everyone's
requirements. i'm also of the mindset that a mtd should not be
created if the SPI flash isnt there simply because the resources say
it might be.
-mike
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Uclinux-dist-devel] Config Items appearing twice in same Kconfig file?
On Wed, May 12, 2010 at 10:40, Christoph Egger wrote: 2 arch/blackfin/Kconfig:config MEM_MT48LC32M8A2_75 thanks, i'll get this simple bug fixed -mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] backlight: mark struct backlight_ops const
On Sat, Feb 20, 2010 at 18:18, Bruno Prémont wrote: drivers/video/bf54x-lq043fb.c | 2 +- drivers/video/bfin-t350mcqb-fb.c | 2 +- Acked-by: Mike Frysinger vap...@gentoo.org -mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] [PATCH] watchdog_info separation and constify
On Tue, Jan 19, 2010 at 16:42, Joe Perches wrote:
On Tue, 2010-01-19 at 22:17 +0100, Wim Van Sebroeck wrote:
-static struct watchdog_info at32_wdt_info = {
+static const struct watchdog_info at32_wdt_info = {
It'd be good to use a consistent structure name:
static const struct watchdog_info ident = {
etc...
}
i'd agree (obviously i'm partial to the xxx_wdt_info form), but i'd
worry about this after the watchdog implementations are finally
unified ... might be less code needing standardization at that point
-mike
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Uclinux-dist-devel] Removing deprecated drivers from drivers/i2c/chips
On Thu, Sep 10, 2009 at 02:26, Wolfram Sang wrote: the Blackfin defconfigs refer to an input driver for the PCF8574, not the I2C client driver Yup, I am aware of that. With the exception of: blackfin/configs/PNAV-10_defconfig:773:CONFIG_SENSORS_PCF8574=m thanks for double checking. i'm not sure this board even has this device. i'll review the hardware. -mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Uclinux-dist-devel] Removing deprecated drivers from drivers/i2c/chips
On Wed, Sep 9, 2009 at 17:22, Wolfram Sang wrote: continuing the quest to clean up and ultimately remove the drivers/i2c/chips directory, this patch series removes three drivers for GPIO-expanders which are obsoleted and marked as deprecated for more than a year. The newer (and better) drivers can be found in drivers/gpio. As it is ensured that the newer drivers cover the same i2c_device_ids, all platform_devices will still match. Some defconfig updates may be necessary though, but according to [1] this is left to the arch|platform-maintainers (also as most defconfigs are quite outdated). For that reason, I put the relevant arch-mailing-lists to Cc. Comments are welcome. the Blackfin defconfigs refer to an input driver for the PCF8574, not the I2C client driver -mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/7] spi: Prefix modalias with spi:
On Wed, Jul 29, 2009 at 13:05, Anton Vorontsov wrote: This makes it consistent with other buses (platform, i2c, vio, ...). I'm not sure why we use the prefixes, but there must be a reason. This was easy enough to do it, and I did it. acked-by-me for misc blackfin/adi drivers, thanks -mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] lib: Provide generic atomic64_t implementation
On Sat, Jun 13, 2009 at 03:10, Paul Mackerras wrote:
+typedef struct {
+ long long counter;
+} atomic64_t;
lack of volatile seems odd compared to:
include/linux/types.h:
typedef struct {
volatile int counter;
} atomic_t;
-mike
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] lib: Provide generic atomic64_t implementation
On Thu, Jun 18, 2009 at 20:47, Paul Mackerras wrote:
Mike Frysinger writes:
On Sat, Jun 13, 2009 at 03:10, Paul Mackerras wrote:
+typedef struct {
+ long long counter;
+} atomic64_t;
lack of volatile seems odd compared to:
include/linux/types.h:
typedef struct {
volatile int counter;
} atomic_t;
It's only accessed under a spinlock, so I don't think it needs to be
volatile. On UP it's accessed within local_irq_save/restore which
should also be compiler barriers and prevent memory access reordering,
so again volatile isn't needed.
i'm not suggesting it is needed, i'm saying it's a bit confusing. a
simple comment above the atomic64_t type with your simple explanation
here would go a long way.
-mike
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] drivers/hvc: add missing __devexit_p()
The remove function uses __devexit, so the .remove assignment needs
__devexit_p() to fix a build error with hotplug disabled.
Signed-off-by: Mike Frysinger vap...@gentoo.org
CC: linuxppc-dev@ozlabs.org
CC: linux-ker...@vger.kernel.org
---
drivers/char/hvc_iseries.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/char/hvc_iseries.c b/drivers/char/hvc_iseries.c
index 449727b..936d05b 100644
--- a/drivers/char/hvc_iseries.c
+++ b/drivers/char/hvc_iseries.c
@@ -241,7 +241,7 @@ static int __devexit hvc_vio_remove(struct vio_dev *vdev)
static struct vio_driver hvc_vio_driver = {
.id_table = hvc_driver_table,
.probe = hvc_vio_probe,
- .remove = hvc_vio_remove,
+ .remove = __devexit_p(hvc_vio_remove),
.driver = {
.name = hvc_driver_name,
.owner = THIS_MODULE,
--
1.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] drivers/hvc: add missing __devexit_p()
The remove function uses __devexit, so the .remove assignment needs
__devexit_p() to fix a build error with hotplug disabled.
Signed-off-by: Mike Frysinger vap...@gentoo.org
CC: linuxppc-dev@ozlabs.org
---
v2
- include all hvc files
drivers/char/hvc_iseries.c |2 +-
drivers/char/hvc_vio.c |2 +-
drivers/char/hvcs.c|2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/char/hvc_iseries.c b/drivers/char/hvc_iseries.c
index 449727b..936d05b 100644
--- a/drivers/char/hvc_iseries.c
+++ b/drivers/char/hvc_iseries.c
@@ -241,7 +241,7 @@ static int __devexit hvc_vio_remove(struct vio_dev *vdev)
static struct vio_driver hvc_vio_driver = {
.id_table = hvc_driver_table,
.probe = hvc_vio_probe,
- .remove = hvc_vio_remove,
+ .remove = __devexit_p(hvc_vio_remove),
.driver = {
.name = hvc_driver_name,
.owner = THIS_MODULE,
diff --git a/drivers/char/hvc_vio.c b/drivers/char/hvc_vio.c
index bd62dc8..c72b994 100644
--- a/drivers/char/hvc_vio.c
+++ b/drivers/char/hvc_vio.c
@@ -113,7 +113,7 @@ static int __devexit hvc_vio_remove(struct vio_dev *vdev)
static struct vio_driver hvc_vio_driver = {
.id_table = hvc_driver_table,
.probe = hvc_vio_probe,
- .remove = hvc_vio_remove,
+ .remove = __devexit_p(hvc_vio_remove),
.driver = {
.name = hvc_driver_name,
.owner = THIS_MODULE,
diff --git a/drivers/char/hvcs.c b/drivers/char/hvcs.c
index c76bccf..2724d62 100644
--- a/drivers/char/hvcs.c
+++ b/drivers/char/hvcs.c
@@ -868,7 +868,7 @@ static int __devexit hvcs_remove(struct vio_dev *dev)
static struct vio_driver hvcs_vio_driver = {
.id_table = hvcs_driver_table,
.probe = hvcs_probe,
- .remove = hvcs_remove,
+ .remove = __devexit_p(hvcs_remove),
.driver = {
.name = hvcs_driver_name,
.owner = THIS_MODULE,
--
1.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
On Tue, Nov 25, 2008 at 13:34, Grant Erickson wrote: This merges support for the previously DENX-only kernel feature of specifying an alternative, external buffer for kernel printk messages and their associated metadata. In addition, this ports architecture support for this feature from arch/ppc to arch/powerpc. Signed-off-by: Grant Erickson [EMAIL PROTECTED] --- When this option is enabled, an architecture- or machine-specific log buffer is used for all printk messages. This allows entities such as boot loaders (e.g. U-Boot) to place printk-compatible messages into this buffer and for the kernel to coalesce them with its normal messages. snip this extended info should be part of the changelog and thus above the --- marker ... -mike ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Merge linuxppc-embedded with linuxppc-dev
On Mon, Sep 22, 2008 at 18:08, Grant Likely [EMAIL PROTECTED] wrote: Jeremy, Can we eliminate the linuxppc-embedded mailing list and merge it with linuxppc-dev? I don't think we need two separate lists anymore and patches to linuxppc-embedded don't always get dealt with. Anyone have any objections to eliminating linuxppc-embedded? you sent this e-mail to linux-embedded instead of linuxppc-embedded -mike ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch] use __attribute__ in asm-powerpc
On Monday 16 July 2007, Geert Uytterhoeven wrote:
On Sat, 14 Jul 2007, Mike Frysinger wrote:
Pretty much everyone uses __attribute__ or attribute, no one
uses __attribute. This patch tweaks the three places in asm-powerpc
where this comes up. While only asm-powerpc/types.h is interesting (for
userspace), I did asm-powerpc/processor.h as well for consistency.
Signed-off-by: Mike Frysinger [EMAIL PROTECTED]
---
diff --git a/include/asm-powerpc/processor.h
b/include/asm-powerpc/processor.h index d947b16..2ce6ea6 100644
--- a/include/asm-powerpc/processor.h
+++ b/include/asm-powerpc/processor.h
@@ -153,9 +153,9 @@ struct thread_struct {
unsigned long dabr; /* Data address breakpoint register */
#ifdef CONFIG_ALTIVEC
/* Complete AltiVec register set */
- vector128 vr[32] __attribute((aligned(16)));
+ vector128 vr[32] __attribute__((aligned(16)));
If the code is not exported to userspace (and thus not subject to different
compilers), I think the preferred form is plain `attribute'.
i never said asm-powerpc/processor.h was exported to userspace ... i did say
that i changed the file to be consistent with all other files.
-mike
signature.asc
Description: This is a digitally signed message part.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
