Re: [PATCH] powerpc/traps: Declare unrecoverable_exception() as __noreturn

On Thu, Feb 11, 2021 at 06:34:43AM +, Christophe Leroy wrote: > unrecoverable_exception() is never expected to return, most callers > have an infiniteloop in case it returns. > > Ensure it really never returns by terminating it with a BUG(), and > declare it __no_return. > > It always GCC to

Re: Re：Re: [PATCH] powerpc: Fix a bug in __div64_32 if divisor is zero

On Sun, Aug 23, 2020 at 12:54:33AM +0800, Guohua Zhong wrote: > >In generic version in lib/math/div64.c, there is no checking of 'base' > >either. > >Do we really want to add this check in the powerpc version only ? > > >The only user of __div64_32() is do_div() in >

Re: [PATCH v2 2/5] powerpc: Allow 4224 bytes of stack expansion for the signal frame

On Fri, Jul 24, 2020 at 07:25:25PM +1000, Michael Ellerman wrote: > We have powerpc specific logic in our page fault handling to decide if > an access to an unmapped address below the stack pointer should expand > the stack VMA. > > The code was originally added in 2004 "ported from 2.4". The

Re: [PATCH v2 3/6] powerpc: Convert flush_icache_range & friends to C

On Tue, Sep 03, 2019 at 01:31:57PM -0500, Segher Boessenkool wrote: > On Tue, Sep 03, 2019 at 07:05:19PM +0200, Christophe Leroy wrote: > > Le 03/09/2019 à 18:04, Segher Boessenkool a écrit : > > >(Why are they separate though? It could just be one loop var). > > > > Yes it could just be a

Re: [PATCH v13 00/10] powerpc: Switch to CONFIG_THREAD_INFO_IN_TASK

On Thu, Jan 24, 2019 at 04:58:41PM +0100, Christophe Leroy wrote: > > > Le 24/01/2019 à 16:01, Christophe Leroy a écrit : > > > > > > Le 24/01/2019 à 10:43, Christophe Leroy a écrit : > > > > > > > > > On 01/24/2019 01:06 AM, Michael Ellerman wrote: > > > > Christophe Leroy writes: > > > >

Re: [PATCH v2 13/29] arch: add split IPC system calls where needed

On Fri, Jan 18, 2019 at 05:18:19PM +0100, Arnd Bergmann wrote: > The IPC system call handling is highly inconsistent across architectures, > some use sys_ipc, some use separate calls, and some use both. We also > have some architectures that require passing IPC_64 in the flags, and > others that

Re: [PATCH] macintosh: Add module license to ans-lcd

On Mon, Jan 29, 2018 at 01:33:08PM -0600, Larry Finger wrote: > In kernel 4.15, the modprobe step on my PowerBook G5 started complaining that PowerBook G5? Really, could you send a pic! :-) > there was no module license for ans-lcd. > > Signed-off-by: Larry Finger

Re: [PATCH] macintosh: Add module license to ans-lcd

On Mon, Jan 29, 2018 at 01:33:08PM -0600, Larry Finger wrote: > In kernel 4.15, the modprobe step on my PowerBook G5 started complaining that PowerBook G5? Really, could you send a pic! :-) > there was no module license for ans-lcd. > > Signed-off-by: Larry Finger > --- >

Re: [PATCH v9 29/51] mm/mprotect, powerpc/mm/pkeys, x86/mm/pkeys: Add sysfs interface

On Mon, Dec 18, 2017 at 03:15:51PM -0800, Ram Pai wrote: > On Mon, Dec 18, 2017 at 02:28:14PM -0800, Dave Hansen wrote: > > On 12/18/2017 02:18 PM, Ram Pai wrote: > > > b) minimum number of keys available to the application. > > > if libraries consumes a few, they could provide a library > > >

Re: [PATCH v9 29/51] mm/mprotect, powerpc/mm/pkeys, x86/mm/pkeys: Add sysfs interface

On Mon, Dec 18, 2017 at 03:15:51PM -0800, Ram Pai wrote: > On Mon, Dec 18, 2017 at 02:28:14PM -0800, Dave Hansen wrote: > > On 12/18/2017 02:18 PM, Ram Pai wrote: > > > b) minimum number of keys available to the application. > > > if libraries consumes a few, they could provide a library > > >

Re: [PATCH][V2] crypto/nx: fix spelling mistake: "availavle" -> "available"

On Tue, Nov 14, 2017 at 02:32:17PM +, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in pr_err error message text. Also > fix spelling mistake in proceeding comment. s/proceeding/preceding/ ? > > Signed-off-by: Colin Ian King

Re: [PATCH][V2] crypto/nx: fix spelling mistake: "availavle" -> "available"

On Tue, Nov 14, 2017 at 02:32:17PM +, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in pr_err error message text. Also > fix spelling mistake in proceeding comment. s/proceeding/preceding/ ? > > Signed-off-by: Colin Ian King > --- >

Re: [PATCH v3 2/5] firmware: annotate thou shalt not request fw on init or probe

On Tue, Aug 23, 2016 at 05:45:04PM -0700, mcg...@kernel.org wrote: [snip] > --- > Documentation/firmware_class/README| 20 > drivers/base/Kconfig | 2 +- > .../request_firmware-avoid-init-probe-init.cocci | 130 > + > 3

Re: [PATCH v3 2/5] firmware: annotate thou shalt not request fw on init or probe

On Tue, Aug 23, 2016 at 05:45:04PM -0700, mcg...@kernel.org wrote: [snip] > --- > Documentation/firmware_class/README| 20 > drivers/base/Kconfig | 2 +- > .../request_firmware-avoid-init-probe-init.cocci | 130 > + > 3

Re: [PATCH] powerpc/8xx: fix single_step debug

On Thu, Aug 18, 2016 at 12:13:21PM +0200, Christophe Leroy wrote: > > > Le 18/08/2016 à 11:58, Gabriel Paubert a écrit : > >On Thu, Aug 18, 2016 at 11:44:20AM +0200, Christophe Leroy wrote: > >>SPRN_ICR must be read for clearing the internal freeze signal which > >&

Re: [PATCH] powerpc/8xx: fix single_step debug

On Thu, Aug 18, 2016 at 12:13:21PM +0200, Christophe Leroy wrote: > > > Le 18/08/2016 à 11:58, Gabriel Paubert a écrit : > >On Thu, Aug 18, 2016 at 11:44:20AM +0200, Christophe Leroy wrote: > >>SPRN_ICR must be read for clearing the internal freeze signal which > >&

Re: [PATCH] powerpc/8xx: fix single_step debug

On Thu, Aug 18, 2016 at 11:44:20AM +0200, Christophe Leroy wrote: > SPRN_ICR must be read for clearing the internal freeze signal which > is asserted by the single step exception, otherwise the timebase and > decrementer remain freezed Minor nit: s/freezed/frozen/ If the timebase and decrementer

Re: [PATCH] powerpc/8xx: fix single_step debug

On Thu, Aug 18, 2016 at 11:44:20AM +0200, Christophe Leroy wrote: > SPRN_ICR must be read for clearing the internal freeze signal which > is asserted by the single step exception, otherwise the timebase and > decrementer remain freezed Minor nit: s/freezed/frozen/ If the timebase and decrementer

Re: [PATCH] powerpc/32: Remove one insn in __bswapdi2

On Thu, Aug 11, 2016 at 05:11:19PM -0500, Segher Boessenkool wrote: > On Thu, Aug 11, 2016 at 11:34:37PM +0200, Gabriel Paubert wrote: > > On the other hand gcc did at the time a very poor job (quite an > > understatement) at bswapdi when compiling for 64 bit processors >

Re: [PATCH] powerpc/32: Remove one insn in __bswapdi2

On Thu, Aug 11, 2016 at 05:11:19PM -0500, Segher Boessenkool wrote: > On Thu, Aug 11, 2016 at 11:34:37PM +0200, Gabriel Paubert wrote: > > On the other hand gcc did at the time a very poor job (quite an > > understatement) at bswapdi when compiling for 64 bit processors >

Re: [PATCH] powerpc/32: Remove one insn in __bswapdi2

On Wed, Aug 10, 2016 at 12:18:15PM +0200, Christophe Leroy wrote: > > > Le 10/08/2016 à 10:56, Gabriel Paubert a écrit : > >On Fri, Aug 05, 2016 at 01:28:02PM +0200, Christophe Leroy wrote: > >>Signed-off-by: Christophe Leroy <christophe.le...@c-s.fr> > >>

Re: [PATCH] powerpc/32: Remove one insn in __bswapdi2

On Wed, Aug 10, 2016 at 12:18:15PM +0200, Christophe Leroy wrote: > > > Le 10/08/2016 à 10:56, Gabriel Paubert a écrit : > >On Fri, Aug 05, 2016 at 01:28:02PM +0200, Christophe Leroy wrote: > >>Signed-off-by: Christophe Leroy > >>--- > >> arch/po

Re: [PATCH] powerpc/32: Remove one insn in __bswapdi2

On Fri, Aug 05, 2016 at 01:28:02PM +0200, Christophe Leroy wrote: > Signed-off-by: Christophe Leroy > --- > arch/powerpc/kernel/misc_32.S | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/arch/powerpc/kernel/misc_32.S

Re: [PATCH] powerpc/32: Remove one insn in __bswapdi2

On Fri, Aug 05, 2016 at 01:28:02PM +0200, Christophe Leroy wrote: > Signed-off-by: Christophe Leroy > --- > arch/powerpc/kernel/misc_32.S | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S > index

Re: [PATCH] powerpc: inline current_stack_pointer()

On Mon, May 23, 2016 at 10:46:02AM +0200, Christophe Leroy wrote: > current_stack_pointeur() is a single instruction function. it > It is not worth breaking the execution flow with a bl/blr for a > single instruction Are you sure that the result is always the same? Calling an external function

Re: [PATCH] powerpc: inline current_stack_pointer()

On Mon, May 23, 2016 at 10:46:02AM +0200, Christophe Leroy wrote: > current_stack_pointeur() is a single instruction function. it > It is not worth breaking the execution flow with a bl/blr for a > single instruction Are you sure that the result is always the same? Calling an external function

Re: [PATCH] powerpc32: use stmw/lmw for non volatile registers save/restore

On Mon, May 23, 2016 at 10:46:36AM +0200, Christophe Leroy wrote: > lmw/stmw have a 1 cycle (2 cycles for lmw on some ppc) in addition > and implies serialising, however it reduces the amount of instructions > hence the amount of instruction fetch compared to the equivalent > operation with

Re: [PATCH] powerpc32: use stmw/lmw for non volatile registers save/restore

On Mon, May 23, 2016 at 10:46:36AM +0200, Christophe Leroy wrote: > lmw/stmw have a 1 cycle (2 cycles for lmw on some ppc) in addition > and implies serialising, however it reduces the amount of instructions > hence the amount of instruction fetch compared to the equivalent > operation with

Re: powerpc: Discard ffs() function and use builtin_ffs instead

On Fri, May 13, 2016 at 04:16:57PM +1000, Michael Ellerman wrote: > On Thu, 2016-12-05 at 15:32:22 UTC, Christophe Leroy wrote: > > With the ffs() function as defined in arch/powerpc/include/asm/bitops.h > > GCC will not optimise the code in case of constant parameter, as shown > > by the small

Re: powerpc: Discard ffs() function and use builtin_ffs instead

On Fri, May 13, 2016 at 04:16:57PM +1000, Michael Ellerman wrote: > On Thu, 2016-12-05 at 15:32:22 UTC, Christophe Leroy wrote: > > With the ffs() function as defined in arch/powerpc/include/asm/bitops.h > > GCC will not optimise the code in case of constant parameter, as shown > > by the small

Re: [1/1] powerpc/embedded6xx: Make reboot works on MVME5100

On Wed, Mar 09, 2016 at 03:26:21PM -0600, Scott Wood wrote: > On Wed, 2016-03-09 at 11:28 +0100, Gabriel Paubert wrote: > > On Wed, Mar 09, 2016 at 12:38:18AM -0600, Scott Wood wrote: > > > On Tue, Mar 08, 2016 at 08:59:12AM +0100, Alessio Igor Bogani wrote: > > > &

Re: [1/1] powerpc/embedded6xx: Make reboot works on MVME5100

On Wed, Mar 09, 2016 at 03:26:21PM -0600, Scott Wood wrote: > On Wed, 2016-03-09 at 11:28 +0100, Gabriel Paubert wrote: > > On Wed, Mar 09, 2016 at 12:38:18AM -0600, Scott Wood wrote: > > > On Tue, Mar 08, 2016 at 08:59:12AM +0100, Alessio Igor Bogani wrote: > > > &

Re: [1/1] powerpc/embedded6xx: Make reboot works on MVME5100

On Wed, Mar 09, 2016 at 12:38:18AM -0600, Scott Wood wrote: > On Tue, Mar 08, 2016 at 08:59:12AM +0100, Alessio Igor Bogani wrote: > > The mtmsr() function hangs during restart. Make reboot works on > > MVME5100 removing that function call. > > --- > >

Re: [1/1] powerpc/embedded6xx: Make reboot works on MVME5100

On Wed, Mar 09, 2016 at 12:38:18AM -0600, Scott Wood wrote: > On Tue, Mar 08, 2016 at 08:59:12AM +0100, Alessio Igor Bogani wrote: > > The mtmsr() function hangs during restart. Make reboot works on > > MVME5100 removing that function call. > > --- > >

Re: [PATCH v2] powerpc/mpc5xxx: Avoid dereferencing potentially freed memory

On Fri, Oct 16, 2015 at 08:20:13AM +0200, Christophe JAILLET wrote: > Le 15/10/2015 08:36, Michael Ellerman a écrit : > >On Thu, 2015-10-15 at 07:56 +0200, Christophe JAILLET wrote: > >>Use 'of_property_read_u32()' instead of 'of_get_property()'+pointer > >>dereference in order to avoid access to

Re: [PATCH v2] powerpc/mpc5xxx: Avoid dereferencing potentially freed memory

On Fri, Oct 16, 2015 at 08:20:13AM +0200, Christophe JAILLET wrote: > Le 15/10/2015 08:36, Michael Ellerman a écrit : > >On Thu, 2015-10-15 at 07:56 +0200, Christophe JAILLET wrote: > >>Use 'of_property_read_u32()' instead of 'of_get_property()'+pointer > >>dereference in order to avoid access to

Re: [RFC] Design for flag bit outputs from asms

On Mon, May 04, 2015 at 12:33:38PM -0700, Richard Henderson wrote: [snipped] > (3) Note that ppc is both easier and more complicated. > > There we have 8 4-bit registers, although most of the integer > non-comparisons only write to CR0. And the vector non-comparisons > only write to CR1,

Re: [RFC] Design for flag bit outputs from asms

On Mon, May 04, 2015 at 12:33:38PM -0700, Richard Henderson wrote: [snipped] (3) Note that ppc is both easier and more complicated. There we have 8 4-bit registers, although most of the integer non-comparisons only write to CR0. And the vector non-comparisons only write to CR1, though

Re: deb-pkg: Add support for powerpc little endian

On Fri, Sep 05, 2014 at 03:28:47PM +1000, Michael Neuling wrote: > The Debian powerpc little endian architecture is called ppc64le. This Huh? ppc64le or ppc64el? > is the default architecture used by Ubuntu for powerpc. > > The below checks the kernel config to see if we are compiling little >

Re: deb-pkg: Add support for powerpc little endian

On Fri, Sep 05, 2014 at 03:28:47PM +1000, Michael Neuling wrote: The Debian powerpc little endian architecture is called ppc64le. This Huh? ppc64le or ppc64el? is the default architecture used by Ubuntu for powerpc. The below checks the kernel config to see if we are compiling little

Re: [PATCH 3/3] perf: Use 64-bit value when comparing sample_regs

On Thu, Mar 06, 2014 at 09:44:47AM +, David Laight wrote: > From: Sukadev Bhattiprolu > > When checking whether a bit representing a register is set in > > sample_regs, a 64-bit mask, use 64-bit value (1LL). > > > > Signed-off-by: Sukadev Bhattiprolu > > --- > > tools/perf/util/unwind.c |

Re: [PATCH 3/3] perf: Use 64-bit value when comparing sample_regs

On Thu, Mar 06, 2014 at 09:44:47AM +, David Laight wrote: From: Sukadev Bhattiprolu When checking whether a bit representing a register is set in sample_regs, a 64-bit mask, use 64-bit value (1LL). Signed-off-by: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com ---

Re: [RFC PATCH] powerpc: add ioremap_wt

On Mon, Feb 03, 2014 at 08:16:49AM +0100, Michael Moese wrote: > Allow for IO memory to be mapped cacheable for performing > PCI read bursts. > > Signed-off-by: Michael Moese > --- > arch/powerpc/include/asm/io.h | 3 +++ > arch/powerpc/mm/pgtable_32.c | 8 > 2 files changed, 11

Re: [RFC PATCH] powerpc: add ioremap_wt

On Mon, Feb 03, 2014 at 08:16:49AM +0100, Michael Moese wrote: Allow for IO memory to be mapped cacheable for performing PCI read bursts. Signed-off-by: Michael Moese michael.mo...@men.de --- arch/powerpc/include/asm/io.h | 3 +++ arch/powerpc/mm/pgtable_32.c | 8 2 files

Re: [PATCH 00/18] ide: warm-plug support for IDE devices and other goodies

On Tue, Feb 12, 2008 at 01:30:03PM +0100, Gabriel Paubert wrote: > On Tue, Feb 12, 2008 at 12:49:05PM +0100, Gabriel Paubert wrote: > > On Fri, Feb 08, 2008 at 07:40:43PM +1100, Benjamin Herrenschmidt wrote: > > > > > > On Fri, 2008-02-08 at 01:44 +0100, Bart

Re: [PATCH 00/18] ide: warm-plug support for IDE devices and other goodies

On Tue, Feb 12, 2008 at 01:30:03PM +0100, Gabriel Paubert wrote: On Tue, Feb 12, 2008 at 12:49:05PM +0100, Gabriel Paubert wrote: On Fri, Feb 08, 2008 at 07:40:43PM +1100, Benjamin Herrenschmidt wrote: On Fri, 2008-02-08 at 01:44 +0100, Bartlomiej Zolnierkiewicz wrote: - couple

Re: [PATCH 00/18] ide: warm-plug support for IDE devices and other goodies

On Tue, Feb 12, 2008 at 12:49:05PM +0100, Gabriel Paubert wrote: > On Fri, Feb 08, 2008 at 07:40:43PM +1100, Benjamin Herrenschmidt wrote: > > > > On Fri, 2008-02-08 at 01:44 +0100, Bartlomiej Zolnierkiewicz wrote: > > > - couple of fixes and preparatory patches > >

Re: [PATCH 00/18] ide: warm-plug support for IDE devices and other goodies

On Fri, Feb 08, 2008 at 07:40:43PM +1100, Benjamin Herrenschmidt wrote: > > On Fri, 2008-02-08 at 01:44 +0100, Bartlomiej Zolnierkiewicz wrote: > > - couple of fixes and preparatory patches > > > > - rework of PowerMac media-bay support ([un]register IDE devices instead of > > [un]registering

Re: [PATCH 00/18] ide: warm-plug support for IDE devices and other goodies

On Tue, Feb 12, 2008 at 12:49:05PM +0100, Gabriel Paubert wrote: On Fri, Feb 08, 2008 at 07:40:43PM +1100, Benjamin Herrenschmidt wrote: On Fri, 2008-02-08 at 01:44 +0100, Bartlomiej Zolnierkiewicz wrote: - couple of fixes and preparatory patches - rework of PowerMac media-bay

Re: [PATCH 00/18] ide: warm-plug support for IDE devices and other goodies

On Fri, Feb 08, 2008 at 07:40:43PM +1100, Benjamin Herrenschmidt wrote: On Fri, 2008-02-08 at 01:44 +0100, Bartlomiej Zolnierkiewicz wrote: - couple of fixes and preparatory patches - rework of PowerMac media-bay support ([un]register IDE devices instead of [un]registering IDE

Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver

On Fri, May 18, 2007 at 05:52:45PM +0100, Matt Sealey wrote: > Kumar Gala wrote: > > > > On May 18, 2007, at 9:48 AM, Thomas Gleixner wrote: > > > >> On Fri, 2007-05-18 at 15:28 +0100, Matt Sealey wrote: > >>> > >>> I think both the MPC52xx GPT0-7 and the SLT0-1 fulfil this fairly > >>> easily.

Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver

On Fri, May 18, 2007 at 05:52:45PM +0100, Matt Sealey wrote: Kumar Gala wrote: On May 18, 2007, at 9:48 AM, Thomas Gleixner wrote: On Fri, 2007-05-18 at 15:28 +0100, Matt Sealey wrote: I think both the MPC52xx GPT0-7 and the SLT0-1 fulfil this fairly easily. There is some

Section mismatch warnings (was Re: [PATCH] early_pfn_to_nid needs to be __meminit)

On Thu, May 10, 2007 at 02:25:52AM +1000, Stephen Rothwell wrote: > since it is referenced by memmap_init_zone (which is __meminit) via the > early_pfn_in_nid macro when CONFIG_NODES_SPAN_OTHER_NODES is set (which > basically means PowerPC 64). > > This removes a section mismatch warning in those

Section mismatch warnings (was Re: [PATCH] early_pfn_to_nid needs to be __meminit)

On Thu, May 10, 2007 at 02:25:52AM +1000, Stephen Rothwell wrote: since it is referenced by memmap_init_zone (which is __meminit) via the early_pfn_in_nid macro when CONFIG_NODES_SPAN_OTHER_NODES is set (which basically means PowerPC 64). This removes a section mismatch warning in those

Re: [PATCH 7/10] local_t : powerpc

On Wed, Jan 24, 2007 at 08:08:12PM +1100, Paul Mackerras wrote: > Mathieu Desnoyers writes: > > > +static __inline__ int local_dec_if_positive(local_t *l) > > +{ > > + int t; > > + > > + __asm__ __volatile__( > > +"1:lwarx %0,0,%1 # local_dec_if_positive\n\ > > + addic.

Re: [PATCH 7/10] local_t : powerpc

On Wed, Jan 24, 2007 at 08:08:12PM +1100, Paul Mackerras wrote: Mathieu Desnoyers writes: +static __inline__ int local_dec_if_positive(local_t *l) +{ + int t; + + __asm__ __volatile__( +1:lwarx %0,0,%1 # local_dec_if_positive\n\ + addic. %0,%0,-1\n\ +

[PATCH] nfs: Fix mismatch between encode_dent_fn and filldir_t

server is run on a 32 bit big-endian machine (it would have been visible on all 32 bit architectures if the 6th parameter had been used). The results are interesting: all files have an inode of 0 (unique you say?) from getdents(2) and even ls(1) does not find any files. Signed-off-by: Gabriel

[PATCH] nfs: Fix mismatch between encode_dent_fn and filldir_t

server is run on a 32 bit big-endian machine (it would have been visible on all 32 bit architectures if the 6th parameter had been used). The results are interesting: all files have an inode of 0 (unique you say?) from getdents(2) and even ls(1) does not find any files. Signed-off-by: Gabriel

Re: 2.6.11-rc5

On Thu, Feb 24, 2005 at 04:57:56PM +0200, M.Baris Demiray wrote: > > Steven Rostedt wrote: > > >[...] > > > >Anyone know if the linux-2.6.11-rc5.tar.bz2 has all the changes in it? > >The tarball rc5 is smaller than rc4. Was there a lot taken out? > > Take a look at the diffview of

Re: 2.6.11-rc5

On Thu, Feb 24, 2005 at 04:57:56PM +0200, M.Baris Demiray wrote: Steven Rostedt wrote: [...] Anyone know if the linux-2.6.11-rc5.tar.bz2 has all the changes in it? The tarball rc5 is smaller than rc4. Was there a lot taken out? Take a look at the diffview of 2.6.11-rc4-rc5 incremental

Re: [PATCH] quiet non-x86 option ROM warnings

On Thu, Feb 17, 2005 at 05:56:03PM -0500, Jon Smirl wrote: > On Fri, 18 Feb 2005 09:45:50 +1100, Benjamin Herrenschmidt > <[EMAIL PROTECTED]> wrote: > > > Can't the size be obtained like any other BAR ? > > yes, but cards that don't fully decode their ROM address space can > waste memory in

Re: [PATCH] quiet non-x86 option ROM warnings

On Thu, Feb 17, 2005 at 05:56:03PM -0500, Jon Smirl wrote: On Fri, 18 Feb 2005 09:45:50 +1100, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: Can't the size be obtained like any other BAR ? yes, but cards that don't fully decode their ROM address space can waste memory in copy_rom. For

Re: high-res-timers start code.

On Mon, 23 Apr 2001, george anzinger wrote: > "Robert H. de Vries" wrote: > > > > On Monday 23 April 2001 19:45, you wrote: > > > > > By the way, is the user land stuff the same for all "arch"s? > > > > Not if you plan to handle the CPU cycle counter in user space. That is at > > least what

Re: high-res-timers start code.

On Mon, 23 Apr 2001, george anzinger wrote: Robert H. de Vries wrote: On Monday 23 April 2001 19:45, you wrote: By the way, is the user land stuff the same for all archs? Not if you plan to handle the CPU cycle counter in user space. That is at least what I would propose.

Re: Kernel Real Time Clock (RTC) Support for I2C Devices

On Wed, 18 Apr 2001, Grant Erickson wrote: > >From the looks of drivers/char/rtc.c it would appear that this kernel > driver only supports bus-attached RTCs such as the mentioned MC146818. Is > this correct? I think so. > > What is the correct access method / kernel tie-in for supporting

Re: Kernel Real Time Clock (RTC) Support for I2C Devices

On Wed, 18 Apr 2001, Grant Erickson wrote: From the looks of drivers/char/rtc.c it would appear that this kernel driver only supports bus-attached RTCs such as the mentioned MC146818. Is this correct? I think so. What is the correct access method / kernel tie-in for supporting such an

Re: missing mxcsr initialization

On Fri, 20 Oct 2000, Andrea Arcangeli wrote: > Many thanks to Doug and Gabriel for very useful explanations about this FPU > stuff. I suggest Gabriel to submit his way faster and more correct tag word > conversion function to Linus for 2.4.x. Here it a first shot, twd_i387_to_fxsr is

Re: missing mxcsr initialization

On Fri, 20 Oct 2000, Andrea Arcangeli wrote: Many thanks to Doug and Gabriel for very useful explanations about this FPU stuff. I suggest Gabriel to submit his way faster and more correct tag word conversion function to Linus for 2.4.x. Here it a first shot, twd_i387_to_fxsr is guaranteed