On Wednesday 02 January 2008, Adrian Bunk wrote:
> On Wed, Jan 02, 2008 at 09:37:50AM -0500, Mike Frysinger wrote:
> > The __GLIBC__ hacks were re-added to the headers because the klibc peeps
> > want to be lazy. But rather than properly address things, they just
> > wrongly
Some arches (like alpha and ia64) already have a clean posix_types.h header.
This brings all the others in line by removing all references to __GLIBC__
(and some undocumented __USE_ALL).
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
asm-arm/posix_types.h |6 +-
asm
-by: Mike Frysinger <[EMAIL PROTECTED]>
---
diff --git a/include/linux/socket.h b/include/linux/socket.h
index c22ef1c..90af15b 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -16,7 +16,7 @@ struct __kernel_sockaddr_storage {
/* _SS_MAXSIZE value
d, possibly by using a copy of the kernel version at any
> > given point of time.
>
> And this is what the current SILO sources do.
then if silo has gotten its stuff together ...
---
Do not export linux/ufs_fs.h to userspace anymore as the only userspace
consumer has been fixed to not need it
On Wednesday 02 January 2008, Ingo Molnar wrote:
> * Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > Forgot to mention this before, but since the msr.h header uses types
> > like __u32, it should pull in linux/types.h.
>
> does not build with the attached config.
sorry
On Wednesday 02 January 2008, Ingo Molnar wrote:
* Mike Frysinger [EMAIL PROTECTED] wrote:
Forgot to mention this before, but since the msr.h header uses types
like __u32, it should pull in linux/types.h.
does not build with the attached config.
sorry, forgot about __ASSEMBLY__ protection
version at any
given point of time.
And this is what the current SILO sources do.
then if silo has gotten its stuff together ...
---
Do not export linux/ufs_fs.h to userspace anymore as the only userspace
consumer has been fixed to not need it anymore.
Signed-off-by: Mike Frysinger [EMAIL
-by: Mike Frysinger [EMAIL PROTECTED]
---
diff --git a/include/linux/socket.h b/include/linux/socket.h
index c22ef1c..90af15b 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -16,7 +16,7 @@ struct __kernel_sockaddr_storage {
/* _SS_MAXSIZE value minus
Some arches (like alpha and ia64) already have a clean posix_types.h header.
This brings all the others in line by removing all references to __GLIBC__
(and some undocumented __USE_ALL).
Signed-off-by: Mike Frysinger [EMAIL PROTECTED]
---
asm-arm/posix_types.h |6 +-
asm-avr32
On Wednesday 02 January 2008, Adrian Bunk wrote:
On Wed, Jan 02, 2008 at 09:37:50AM -0500, Mike Frysinger wrote:
The __GLIBC__ hacks were re-added to the headers because the klibc peeps
want to be lazy. But rather than properly address things, they just
wrongly left it as __GLIBC__
On Jan 2, 2008 1:47 PM, David Brownell [EMAIL PROTECTED] wrote:
On Wednesday 02 January 2008, Robin Getz wrote:
From: Robin Getz [EMAIL PROTECTED]
Allow embedded developers to turn support for USB Hubs off even if they
have a
full root hub. This saves the overhead (RAM and Flash size).
Fix the ufs_inotofsba macro to use __u64 rather than u64 since this is
exported to userspace.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
diff --git a/include/linux/ufs_fs.h b/include/linux/ufs_fs.h
index 10b854d..35b6e59 100644
--- a/include/linux/ufs_fs.h
+++ b/include/linux/uf
Forgot to mention this before, but since the msr.h header uses types like
__u32, it should pull in linux/types.h.
Signed-Off-By: Mike Frysinger <[EMAIL PROTECTED]>
---
diff --git a/include/asm-x86/msr.h b/include/asm-x86/msr.h
index ba4b314..beea1bf 100644
--- a/include/asm-x86/msr.h
On Tuesday 01 January 2008, Christoph Hellwig wrote:
> On Mon, Dec 31, 2007 at 01:12:45PM -0500, Mike Frysinger wrote:
> > Since asm-x86/byteorder.h is exported to userspace, use __asm__ rather
> > than asm in its code.
>
> The correct fix is to not export it to userspace.
On Tuesday 01 January 2008, Christoph Hellwig wrote:
On Mon, Dec 31, 2007 at 01:12:45PM -0500, Mike Frysinger wrote:
Since asm-x86/byteorder.h is exported to userspace, use __asm__ rather
than asm in its code.
The correct fix is to not export it to userspace.
which is what people
Forgot to mention this before, but since the msr.h header uses types like
__u32, it should pull in linux/types.h.
Signed-Off-By: Mike Frysinger [EMAIL PROTECTED]
---
diff --git a/include/asm-x86/msr.h b/include/asm-x86/msr.h
index ba4b314..beea1bf 100644
--- a/include/asm-x86/msr.h
+++ b/include
Fix the ufs_inotofsba macro to use __u64 rather than u64 since this is
exported to userspace.
Signed-off-by: Mike Frysinger [EMAIL PROTECTED]
---
diff --git a/include/linux/ufs_fs.h b/include/linux/ufs_fs.h
index 10b854d..35b6e59 100644
--- a/include/linux/ufs_fs.h
+++ b/include/linux/ufs_fs.h
Use __asm__ and __volatile__ in code that is exported to userspace. Wrap
kernel functions with __KERNEL__ so they get scrubbed.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
diff --git a/include/asm-x86/msr.h b/include/asm-x86/msr.h
index ba4b314..664a2fa 100644
--- a/include/a
Since asm-x86/byteorder.h is exported to userspace, use __asm__ rather than
asm in its code.
Signed-Off-By: Mike Frysinger <[EMAIL PROTECTED]>
---
diff --git a/include/asm-x86/byteorder.h b/include/asm-x86/byteorder.h
index 1f2d6d5..fe2f2e5 100644
--- a/include/asm-x86/byteorder.h
+++ b/i
. That's an
> unfortunate regression.
i dont see how when the exported code has prototypes with "u32" types in them.
but at any rate ...
---
Use __asm__ and __volatile__ in code that is exported to userspace. Wrap
kernel functions with __KERNEL__ so they get scrubbed.
Signed-off-by: M
On Monday 31 December 2007, Andi Kleen wrote:
> Mike Frysinger <[EMAIL PROTECTED]> writes:
> > The current asm-x86/msr.h does not actually define anything for
> > (!__KERNEL__ && __i386__). For x86_64, it fails to build due to u32/u64
> > types being used. Sim
On Monday 31 December 2007, Andi Kleen wrote:
Mike Frysinger [EMAIL PROTECTED] writes:
The current asm-x86/msr.h does not actually define anything for
(!__KERNEL__ __i386__). For x86_64, it fails to build due to u32/u64
types being used. Simply not installing the header seems easiest
the exported code has prototypes with u32 types in them.
but at any rate ...
---
Use __asm__ and __volatile__ in code that is exported to userspace. Wrap
kernel functions with __KERNEL__ so they get scrubbed.
Signed-off-by: Mike Frysinger [EMAIL PROTECTED]
---
diff --git a/include/asm-x86/msr.h b
Since asm-x86/byteorder.h is exported to userspace, use __asm__ rather than
asm in its code.
Signed-Off-By: Mike Frysinger [EMAIL PROTECTED]
---
diff --git a/include/asm-x86/byteorder.h b/include/asm-x86/byteorder.h
index 1f2d6d5..fe2f2e5 100644
--- a/include/asm-x86/byteorder.h
+++ b/include/asm
Use __asm__ and __volatile__ in code that is exported to userspace. Wrap
kernel functions with __KERNEL__ so they get scrubbed.
Signed-off-by: Mike Frysinger [EMAIL PROTECTED]
---
diff --git a/include/asm-x86/msr.h b/include/asm-x86/msr.h
index ba4b314..664a2fa 100644
--- a/include/asm-x86/msr.h
therwise it's just a
pointless empty header.
Signed-Off-By: Mike Frysinger <[EMAIL PROTECTED]>
---
diff --git a/include/asm-x86/Kbuild b/include/asm-x86/Kbuild
index 12db5a1..6453804 100644
--- a/include/asm-x86/Kbuild
+++ b/include/asm-x86/Kbuild
@@ -4,7 +4,6 @@ header-y += boot.h
header-y
it's just a
pointless empty header.
Signed-Off-By: Mike Frysinger [EMAIL PROTECTED]
---
diff --git a/include/asm-x86/Kbuild b/include/asm-x86/Kbuild
index 12db5a1..6453804 100644
--- a/include/asm-x86/Kbuild
+++ b/include/asm-x86/Kbuild
@@ -4,7 +4,6 @@ header-y += boot.h
header-y += bootparam.h
On Thursday 27 December 2007, Joe Perches wrote:
> On Thu, 2007-12-27 at 16:52 +, Adrian McMenamin wrote:
> > This patch adds support for the CD-Rom drive on the SEGA Dreamcast.
>
> Because it was already so close, might as well make it checkpatch clean.
for the 80 col limit, that's up to the
On Thursday 27 December 2007, Paul Mundt wrote:
> On Thu, Dec 27, 2007 at 01:26:47AM +, Adrian McMenamin wrote:
> > +static int gdrom_get_last_session(struct cdrom_device_info *cd_info,
> > struct cdrom_multisession *ms_info) +{
> > + int fentry, lentry, track, data, tocuse, err;
> > +
On Thursday 27 December 2007, Paul Mundt wrote:
On Thu, Dec 27, 2007 at 01:26:47AM +, Adrian McMenamin wrote:
+static int gdrom_get_last_session(struct cdrom_device_info *cd_info,
struct cdrom_multisession *ms_info) +{
+ int fentry, lentry, track, data, tocuse, err;
+
On Thursday 27 December 2007, Joe Perches wrote:
On Thu, 2007-12-27 at 16:52 +, Adrian McMenamin wrote:
This patch adds support for the CD-Rom drive on the SEGA Dreamcast.
Because it was already so close, might as well make it checkpatch clean.
for the 80 col limit, that's up to the
On Sunday 23 December 2007, Adrian McMenamin wrote:
> On 23/12/2007, Adrian McMenamin <[EMAIL PROTECTED]> wrote:
> > This patch adds support for the CD-Rom (the so-called "GD-Rom") on the
> > SEGA Dreamcast.
> >
> > The GD-Rom is based on the ATA-3 standard but implements a proprietary
> > packet
On Sunday 23 December 2007, Adrian McMenamin wrote:
On 23/12/2007, Adrian McMenamin [EMAIL PROTECTED] wrote:
This patch adds support for the CD-Rom (the so-called GD-Rom) on the
SEGA Dreamcast.
The GD-Rom is based on the ATA-3 standard but implements a proprietary
packet interface - the
On Thursday 20 December 2007, Adrian McMenamin wrote:
> On 20/12/2007, Adrian McMenamin <[EMAIL PROTECTED]> wrote:
> > This patch adds support for the CD Rom device (called a "GD Rom") on
> > the SEGA Dreamcast.This device has a command block similar to a
> > standard ATA-3 device, though
On Thursday 20 December 2007, Adrian McMenamin wrote:
On 20/12/2007, Adrian McMenamin [EMAIL PROTECTED] wrote:
This patch adds support for the CD Rom device (called a GD Rom) on
the SEGA Dreamcast.This device has a command block similar to a
standard ATA-3 device, though implements Sega's
On Dec 20, 2007 11:18 AM, Josh Boyer <[EMAIL PROTECTED]> wrote:
> Rework the architecture specific Makefiles to use the in-kernel version
> of the mkimage tool.
>
> Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
>
> arch/blackfin/boot/Makefile |4 ++--
we dont particularlly care one way or
On Dec 20, 2007 11:18 AM, Josh Boyer [EMAIL PROTECTED] wrote:
Rework the architecture specific Makefiles to use the in-kernel version
of the mkimage tool.
Signed-off-by: Josh Boyer [EMAIL PROTECTED]
arch/blackfin/boot/Makefile |4 ++--
we dont particularlly care one way or the other
On Dec 17, 2007 2:30 PM, Joe Perches <[EMAIL PROTECTED]> wrote:
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
> ---
> arch/blackfin/kernel/early_printk.c |2 +-
> arch/blackfin/mach-bf548/ints-priority.c |2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
thanks, this has
On Dec 17, 2007 2:30 PM, Joe Perches [EMAIL PROTECTED] wrote:
Signed-off-by: Joe Perches [EMAIL PROTECTED]
---
arch/blackfin/kernel/early_printk.c |2 +-
arch/blackfin/mach-bf548/ints-priority.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
thanks, this has been
On Saturday 15 December 2007, Adrian McMenamin wrote:
> diff -ruN ./linux-2.6-orig/drivers/sh/gdrom/gdrom.c
> ./linux-2.6/drivers/sh/gdrom/gdrom.c
i think your e-mail client word wrapped a little ...
> + if (gd.toc)
> + kfree(gd.toc);
i dont know how the kernel functions, but in
On Saturday 15 December 2007, Adrian McMenamin wrote:
diff -ruN ./linux-2.6-orig/drivers/sh/gdrom/gdrom.c
./linux-2.6/drivers/sh/gdrom/gdrom.c
i think your e-mail client word wrapped a little ...
+ if (gd.toc)
+ kfree(gd.toc);
i dont know how the kernel functions, but in
On Dec 14, 2007 3:55 PM, Robert Schwebel <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 14, 2007 at 03:35:36PM -0500, Mike Frysinger wrote:
> > > Upstream plus a well defined patch stack with well documented patches
> > > would definitely be preferred here.
>
> Well, te
On Dec 14, 2007 3:28 PM, Robert Schwebel <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 14, 2007 at 03:21:45PM -0500, Mike Frysinger wrote:
> > > Is an upstream toolchain available which is able to build blackfin?
> >
> > binutils -- yes
> > uClibc -- yes (for FLAT)
&
On Dec 14, 2007 3:03 PM, Robert Schwebel <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 13, 2007 at 08:56:17PM +0100, Adrian Bunk wrote:
> > AFAIK the latest available AVR32 toolchains are some patched gcc 4.0 and
> > some patched binutils 2.17, and avr32 is currently the only architecture
> > in the
On Dec 14, 2007 3:03 PM, Robert Schwebel [EMAIL PROTECTED] wrote:
On Thu, Dec 13, 2007 at 08:56:17PM +0100, Adrian Bunk wrote:
AFAIK the latest available AVR32 toolchains are some patched gcc 4.0 and
some patched binutils 2.17, and avr32 is currently the only architecture
in the kernel
On Dec 14, 2007 3:28 PM, Robert Schwebel [EMAIL PROTECTED] wrote:
On Fri, Dec 14, 2007 at 03:21:45PM -0500, Mike Frysinger wrote:
Is an upstream toolchain available which is able to build blackfin?
binutils -- yes
uClibc -- yes (for FLAT)
gcc -- yes and no
we have some pieces
On Dec 14, 2007 3:55 PM, Robert Schwebel [EMAIL PROTECTED] wrote:
On Fri, Dec 14, 2007 at 03:35:36PM -0500, Mike Frysinger wrote:
Upstream plus a well defined patch stack with well documented patches
would definitely be preferred here.
Well, tell me that it is wrong, but isn't it common
On Dec 4, 2007 11:41 AM, Alessandro Zummo <[EMAIL PROTECTED]> wrote:
> it should be EINVAL. at least it is wat rtc-cmos does when the value
> is invalid.
in the example rtc test code (Documentation/rtc.txt), would it be
useful to handle EINVAL ? if the freq isnt supported, just say
"hardware
On Dec 4, 2007 11:49 AM, Alessandro Zummo <[EMAIL PROTECTED]> wrote:
> On Tue, 4 Dec 2007 11:47:56 -0500
> "Mike Frysinger" <[EMAIL PROTECTED]> wrote:
> > the return of ENOTTY is to say "changing of freq isnt supported", not
> > that the
On Dec 4, 2007 11:41 AM, Alessandro Zummo <[EMAIL PROTECTED]> wrote:
> On Tue, 4 Dec 2007 11:29:11 -0500 "Mike Frysinger" <[EMAIL PROTECTED]> wrote:
> > On Dec 4, 2007 11:26 AM, Alessandro Zummo <[EMAIL PROTECTED]> wrote:
> > > Bryan Wu <[EMAIL PROT
On Dec 4, 2007 11:26 AM, Alessandro Zummo <[EMAIL PROTECTED]> wrote:
> Bryan Wu <[EMAIL PROTECTED]> wrote:
>
> Hi, I fannly got some time to review the patches. Seems ok, the
> only question is...
>
> > static int bfin_irq_set_freq(struct device *dev, int freq)
> > {
> > - struct bfin_rtc
On Dec 4, 2007 11:26 AM, Alessandro Zummo [EMAIL PROTECTED] wrote:
Bryan Wu [EMAIL PROTECTED] wrote:
Hi, I fannly got some time to review the patches. Seems ok, the
only question is...
static int bfin_irq_set_freq(struct device *dev, int freq)
{
- struct bfin_rtc *rtc =
On Dec 4, 2007 11:41 AM, Alessandro Zummo [EMAIL PROTECTED] wrote:
On Tue, 4 Dec 2007 11:29:11 -0500 Mike Frysinger [EMAIL PROTECTED] wrote:
On Dec 4, 2007 11:26 AM, Alessandro Zummo [EMAIL PROTECTED] wrote:
Bryan Wu [EMAIL PROTECTED] wrote:
Hi, I fannly got some time to review
On Dec 4, 2007 11:49 AM, Alessandro Zummo [EMAIL PROTECTED] wrote:
On Tue, 4 Dec 2007 11:47:56 -0500
Mike Frysinger [EMAIL PROTECTED] wrote:
the return of ENOTTY is to say changing of freq isnt supported, not
that the value is invalid. but i can get the same behavior by
deleting
On Dec 4, 2007 11:41 AM, Alessandro Zummo [EMAIL PROTECTED] wrote:
it should be EINVAL. at least it is wat rtc-cmos does when the value
is invalid.
in the example rtc test code (Documentation/rtc.txt), would it be
useful to handle EINVAL ? if the freq isnt supported, just say
hardware does
On Nov 11, 2007 5:52 PM, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> >> Nack, we shoiuld never include userspace headers in kernel headers,
> >> an even more never add !__KERNEL__ ifdefs. Just make sure your
> >> programs include limit.h before including linux/cdrom.h.
> >
> >I think header files
the current checkpatch.pl does not reject new files that lack a
newline, yet rejects patches that fix newlines in files ... quite the
opposite of what we actually want
$ echo -n moo > no-newline
$ diff -Nu /dev/null no-newline
--- /dev/null 2007-11-10 20:02:36.24800 -0500
+++ no-newline
the current checkpatch.pl does not reject new files that lack a
newline, yet rejects patches that fix newlines in files ... quite the
opposite of what we actually want
$ echo -n moo no-newline
$ diff -Nu /dev/null no-newline
--- /dev/null 2007-11-10 20:02:36.24800 -0500
+++ no-newline
On Nov 11, 2007 5:52 PM, Jan Engelhardt [EMAIL PROTECTED] wrote:
Nack, we shoiuld never include userspace headers in kernel headers,
an even more never add !__KERNEL__ ifdefs. Just make sure your
programs include limit.h before including linux/cdrom.h.
I think header files should be
ggers the error code path, so update those as well.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
diff --git a/scripts/genksyms/genksyms.c b/scripts/genksyms/genksyms.c
index 511023b..dca5e0d 100644
--- a/scripts/genksyms/genksyms.c
+++ b/scripts/genksyms/genksyms.c
@@ -440,17 +440,21 @@
-by: Mike Frysinger [EMAIL PROTECTED]
---
diff --git a/scripts/genksyms/genksyms.c b/scripts/genksyms/genksyms.c
index 511023b..dca5e0d 100644
--- a/scripts/genksyms/genksyms.c
+++ b/scripts/genksyms/genksyms.c
@@ -440,17 +440,21 @@ void error_with_pos(const char *fmt, ...)
static void genksyms_usage
On Nov 9, 2007 6:32 PM, Jiri Slaby <[EMAIL PROTECTED]> wrote:
> bfin_wdt, remove SPIN_LOCK_UNLOCKED
>
> SPIN_LOCK_UNLOCKED is deprecated, use DEFINE_SPINLOCK instead
thanks
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
-mike
-
To unsubscribe from this list: send the li
On Nov 9, 2007 6:32 PM, Jiri Slaby [EMAIL PROTECTED] wrote:
bfin_wdt, remove SPIN_LOCK_UNLOCKED
SPIN_LOCK_UNLOCKED is deprecated, use DEFINE_SPINLOCK instead
thanks
Signed-off-by: Mike Frysinger [EMAIL PROTECTED]
-mike
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Nov 8, 2007 9:09 AM, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
> asm-blackfin
> FLASH_SPEED_BHT
> MEM_MT46V32M16
> MEM_MT48LC16M8A2TG_75
these are and they arent ... the file they're found in is slated for
tossing (after rewriting the functionality it provides), so until then
On Nov 8, 2007 9:09 AM, Robert P. J. Day [EMAIL PROTECTED] wrote:
asm-blackfin
FLASH_SPEED_BHT
MEM_MT46V32M16
MEM_MT48LC16M8A2TG_75
these are and they arent ... the file they're found in is slated for
tossing (after rewriting the functionality it provides), so until then
it'll
On 11/7/07, David Howells <[EMAIL PROTECTED]> wrote:
> arch/blackfin/kernel/bfin_ksyms.c |1 -
> arch/blackfin/kernel/process.c |7 +--
> include/asm-blackfin/a.out.h|6 --
> include/asm-blackfin/processor.h|4
we're going to opt to simply delete
The max_user_freq member is not really meant for RTC drivers to modify, so
update the rtc documentation so drivers writers know what is expected of them
when handling periodic events.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
diff --git a/Documentation/rtc.txt b/Documentation/r
The max_user_freq member is not really meant for RTC drivers to modify, so
update the rtc documentation so drivers writers know what is expected of them
when handling periodic events.
Signed-off-by: Mike Frysinger [EMAIL PROTECTED]
---
diff --git a/Documentation/rtc.txt b/Documentation/rtc.txt
On 11/7/07, David Howells [EMAIL PROTECTED] wrote:
arch/blackfin/kernel/bfin_ksyms.c |1 -
arch/blackfin/kernel/process.c |7 +--
include/asm-blackfin/a.out.h|6 --
include/asm-blackfin/processor.h|4
we're going to opt to simply delete any
On Nov 6, 2007 10:39 PM, Bryan Wu <[EMAIL PROTECTED]> wrote:
> On Nov 7, 2007 11:28 AM, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > On Wed, Nov 07, 2007 at 11:07:06AM +0800, Bryan Wu wrote:
> > > On 11/6/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > > > This patch removes the unused dump_thread().
On Nov 6, 2007 10:39 PM, Bryan Wu [EMAIL PROTECTED] wrote:
On Nov 7, 2007 11:28 AM, Adrian Bunk [EMAIL PROTECTED] wrote:
On Wed, Nov 07, 2007 at 11:07:06AM +0800, Bryan Wu wrote:
On 11/6/07, Adrian Bunk [EMAIL PROTECTED] wrote:
This patch removes the unused dump_thread().
Why only
On 11/5/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
> arch/blackfin/mm/blackfin_sram.c:#include
> arch/blackfin/mach-common/interrupt.S:#include
i seem to recall these already getting fixed, but just in case, ive
queued up patches for these
cheers
-mike
-
To unsubscribe from this list:
On 11/5/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
> this list is short enough that i'll just post it here -- attempts to
> include header files under include/linux when those header files
> simply don't exist. obviously, there might be false positives for one
> reason or another.
On 11/5/07, Robert P. J. Day [EMAIL PROTECTED] wrote:
this list is short enough that i'll just post it here -- attempts to
include header files under include/linux when those header files
simply don't exist. obviously, there might be false positives for one
reason or another.
obviously the
On 11/5/07, Robert P. J. Day [EMAIL PROTECTED] wrote:
arch/blackfin/mm/blackfin_sram.c:#include linux/autoconf.h
arch/blackfin/mach-common/interrupt.S:#include linux/autoconf.h
i seem to recall these already getting fixed, but just in case, ive
queued up patches for these
cheers
-mike
-
To
On 10/30/07, Bryan Wu <[EMAIL PROTECTED]> wrote:
> --- a/drivers/i2c/busses/i2c-bfin-twi.c
> +++ b/drivers/i2c/busses/i2c-bfin-twi.c
> +static int setup_pin_mux(int action, struct bfin_twi_iface *iface)
> +{
> +
> + u16 pin_req[2][3] = {
> + {P_TWI0_SCL, P_TWI0_SDA, 0},
> +
On 10/30/07, Bryan Wu [EMAIL PROTECTED] wrote:
--- a/drivers/i2c/busses/i2c-bfin-twi.c
+++ b/drivers/i2c/busses/i2c-bfin-twi.c
+static int setup_pin_mux(int action, struct bfin_twi_iface *iface)
+{
+
+ u16 pin_req[2][3] = {
+ {P_TWI0_SCL, P_TWI0_SDA, 0},
+
On 10/31/07, David Brownell <[EMAIL PROTECTED]> wrote:
> On Wednesday 31 October 2007, Mike Frysinger wrote:
> > On 10/31/07, David Brownell <[EMAIL PROTECTED]> wrote:
> > > (ISTR the M25P16 in $SUBJECT has two read commands, one of
> > > which is only u
On 10/31/07, David Brownell <[EMAIL PROTECTED]> wrote:
> (ISTR the M25P16 in $SUBJECT has two read commands, one of
> which is only usable at clock rates below 33 MHz or so, but
> most other commands can work above that speed just fine.)
pretty much all SPI flashes have two read commands ("slow"
On 10/31/07, David Brownell [EMAIL PROTECTED] wrote:
(ISTR the M25P16 in $SUBJECT has two read commands, one of
which is only usable at clock rates below 33 MHz or so, but
most other commands can work above that speed just fine.)
pretty much all SPI flashes have two read commands (slow and
On 10/31/07, David Brownell [EMAIL PROTECTED] wrote:
On Wednesday 31 October 2007, Mike Frysinger wrote:
On 10/31/07, David Brownell [EMAIL PROTECTED] wrote:
(ISTR the M25P16 in $SUBJECT has two read commands, one of
which is only usable at clock rates below 33 MHz or so, but
most
On 10/30/07, Kirill A. Shutemov <[EMAIL PROTECTED]> wrote:
> asm/elf.h, asm/page.h and asm/user.h don't export to userspace now
as long as this is true ...
> we can drop #ifdef __KERNEL__ for them.
... this sounds great ... thanks (for Blackfin bits) :)
-mike
-
To unsubscribe from this list:
On 10/30/07, David Brownell <[EMAIL PROTECTED]> wrote:
> And also, pay closer attention to when you may be making
> changes that make device drivers work differently over
> your spi_master controller driver than anyone elses ...
> such platform-specific behaviors are undesirable, and when
> they
On 10/30/07, David Brownell [EMAIL PROTECTED] wrote:
And also, pay closer attention to when you may be making
changes that make device drivers work differently over
your spi_master controller driver than anyone elses ...
such platform-specific behaviors are undesirable, and when
they go
On 10/30/07, Kirill A. Shutemov [EMAIL PROTECTED] wrote:
asm/elf.h, asm/page.h and asm/user.h don't export to userspace now
as long as this is true ...
we can drop #ifdef __KERNEL__ for them.
... this sounds great ... thanks (for Blackfin bits) :)
-mike
-
To unsubscribe from this list: send
On 10/27/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> I recently noticed that all architectures appear to have an entry n
> struct user called u_ar0:
>
>struct user_pt_regs * u_ar0; /* Used by gdb to help find the values
> for */
> /* the registers. */
>
>
On 10/27/07, H. Peter Anvin [EMAIL PROTECTED] wrote:
I recently noticed that all architectures appear to have an entry n
struct user called u_ar0:
struct user_pt_regs * u_ar0; /* Used by gdb to help find the values
for */
/* the registers. */
In all
On 10/25/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> Mike Frysinger wrote:
> >> Do you have any example for your claim "to get gcc to not inline things
> >> when building debug versions"?
> >
> > $ cat test.c
> > __attribute__((always
On 10/25/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 25, 2007 at 04:07:45PM -0400, Mike Frysinger wrote:
> > On 10/25/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > > On Thu, Oct 25, 2007 at 12:16:40PM -0400, Mike Frysinger wrote:
> > > >
On 10/25/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 25, 2007 at 12:16:40PM -0400, Mike Frysinger wrote:
> > On 10/25/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > > On Wed, Oct 24, 2007 at 08:06:14PM -0700, H. Peter Anvin wrote:
> > > >
On 10/25/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 24, 2007 at 08:06:14PM -0700, H. Peter Anvin wrote:
> > Mike Frysinger wrote:
> >> we'll have to either use the gcc attributes to force old inline
> >> behavior or use the gcc flag to force i
On 10/25/07, Adrian Bunk [EMAIL PROTECTED] wrote:
On Wed, Oct 24, 2007 at 08:06:14PM -0700, H. Peter Anvin wrote:
Mike Frysinger wrote:
we'll have to either use the gcc attributes to force old inline
behavior or use the gcc flag to force it
We should probably have an extern_inline
On 10/25/07, Adrian Bunk [EMAIL PROTECTED] wrote:
On Thu, Oct 25, 2007 at 12:16:40PM -0400, Mike Frysinger wrote:
On 10/25/07, Adrian Bunk [EMAIL PROTECTED] wrote:
On Wed, Oct 24, 2007 at 08:06:14PM -0700, H. Peter Anvin wrote:
Mike Frysinger wrote:
we'll have to either use the gcc
On 10/25/07, Adrian Bunk [EMAIL PROTECTED] wrote:
On Thu, Oct 25, 2007 at 04:07:45PM -0400, Mike Frysinger wrote:
On 10/25/07, Adrian Bunk [EMAIL PROTECTED] wrote:
On Thu, Oct 25, 2007 at 12:16:40PM -0400, Mike Frysinger wrote:
On 10/25/07, Adrian Bunk [EMAIL PROTECTED] wrote
On 10/25/07, H. Peter Anvin [EMAIL PROTECTED] wrote:
Mike Frysinger wrote:
Do you have any example for your claim to get gcc to not inline things
when building debug versions?
$ cat test.c
__attribute__((always_inline)) int foo(void) { return 0; }
int main(void){ return foo
On 10/24/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> Mike Frysinger wrote:
> > On 10/24/07, Jie Zhang <[EMAIL PROTECTED]> wrote:
> >> On 10/25/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >>> "extern inline" will have different sema
On 10/24/07, Jie Zhang <[EMAIL PROTECTED]> wrote:
> On 10/25/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > "extern inline" will have different semantics with gcc 4.3.
> >
> > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> >
> > --- a/include/asm-blackfin/string.h
> > +++
On 10/24/07, Robin Getz <[EMAIL PROTECTED]> wrote:
> - make the check dependant on extratext being populated
> ===
> --- linux-2.6.x/kernel/kallsyms.c (revision 3760)
> +++ linux-2.6.x/kernel/kallsyms.c (working copy)
>
On 10/24/07, Ralf Baechle <[EMAIL PROTECTED]> wrote:
> Nothing should ever include this file.
>
> Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
>
> arch/blackfin/mach-common/interrupt.S |1 -
> arch/blackfin/mm/blackfin_sram.c |1 -
sounds good, thanks
-mike
-
To unsubscribe from
On 10/24/07, Jie Zhang [EMAIL PROTECTED] wrote:
On 10/25/07, Adrian Bunk [EMAIL PROTECTED] wrote:
extern inline will have different semantics with gcc 4.3.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
--- a/include/asm-blackfin/string.h
+++ b/include/asm-blackfin/string.h
@@ -4,7
301 - 400 of 873 matches
Mail list logo
