* Re: Why is Nvidia given GPL'd code to use in proprietary drivers?
From: Richard Stallman @ 2003-01-12 11:55 UTC (permalink / raw)
To: Hell.Surfers; +Cc: linux-kernel
In-Reply-To: <0b96f3916170a13DTVMAIL1@smtp.cwctv.net>
Thank you for forwarding that message to me.
Any attempt to discuss an ethical issue, any statement about what is
right or wrong, is likely to encounter obstructive responses. One
common obstructive response is to change the subject from "What
conduct is right?" to "Who decides?" For instance,
*I* get to decide what brings value to me and what I consider to be
freedom.
Everyone here believes in freedom of thought, as far as I know, but he
is arguing with some imaginary person who he imagines tries to say he
has no right to decide his own views.
Apparently that imaginary person was unsuccessful, because the writer
has stated his views clearly.
I, for one, put my money where my mouth is. I am squarely in the Open
Software movement. I support (with money) NVidia, Code Weavers, and in
the past, 4 Front Technologies, for example.
We see here a person who doesn't particularly care about freedom to
cooperate with others. His statement indeed reflects the values of
the Open Source Movement. (I think "open software" was a slip of the
keyboard; later on he did write "open source".) That movement denies
that freedom to cooperate is an ethical imperative, and considers it
just a convenience.
Millions of people who use free software have views like this today,
and millions more have never heard or considered the question. No one
can deny that. But those people, even numbering millions, would never
have developed a free operating system like GNU/Linux, because they
don't particularly feel it is important to have one.
The reason GNU/Linux exists as a free operating systems is because of
people who do care.
Communism advocates public ownership of *all* property and you advocate
public ownership of *all* software.
"Public ownership" means that the government decides what to do. We
believe that you should really own your copies of software. You
should decide what to change, and when to redistribute it. This is
not much like Communism. Communism operated by command; free software
recruits voluntary cooperation. Communism failed; free software is
succeeding.
Calling us Communists is actually a second method of evading the
issue. Instead of confronting our actual views, they can attack
Communism. Communism is easy to attack.
^ permalink raw reply
* Re: Nvidia and its choice to read the GPL "differently"
From: Richard Stallman @ 2003-01-12 11:55 UTC (permalink / raw)
To: R.E.Wolff; +Cc: jalvo, linux-kernel
In-Reply-To: <20030110194145.A16712@bitwizard.nl>
> It would be reasonable, if not for the fact that it gives the wrong
> idea of who developed the system and--above all--why.
Then -==YOU==- are completely mistaken about why -==I==- contributed
to Linux (the kernel & the system).
By now, many people have contributed for many reasons, to Linux and to
the GNU/Linux system. I do not claim to speak for you; I am talking
about why the system exists in the first place. It is not a haphazard
collection of components. In the GNU Project, we systematically wrote
one component after another. Our goal was a completely free system,
and we took step after step to reach it.
Thank you for contributing, whatever your motives were.
There is a reason why I am not named Mark Mielke-Newman, and our newborn
son is not named Ethan Mielke-Herighty-Newman-Marr.
It isn't a good analogy. Your son wasn't developed by starting with
you and adding some pieces.
^ permalink raw reply
* Re: Why is Nvidia given GPL'd code to use in closed source drivers?
From: Richard Stallman @ 2003-01-12 11:54 UTC (permalink / raw)
To: randall; +Cc: linux-kernel
In-Reply-To: <20030110101043.A19070@uph.com>
I also note that you didn't start your campaign to rename it lignux or
GNU/Linux until it was well established and very commonly known as Linux.
I think we started in 1994 (although mostly privately until 1996).
To a lot of people, myself included, this feels like an attempt to steal
credit and draw attention to yourself and the FSF by trying to hijack the
name of a project that you didn't contribute to, but instead used tools you
provided such as gcc and glibc.
If you believe this is a "project that we didn't contribute to", it's
natural you would believe the rest. That's why calling the system
"Linux" is so unfair. We started developing this system, and we
developed more of it than anyone else; but thinking of it as "Linux"
leads people to focus on the part that we didn't do, and devalue our
part. (See http://www.gnu.org/gnu/gnu-linux-faq.html#tools.)
That's why we can never go along with calling the system "Linux". No matter
how many people do that, we will keep on pointing out why that is wrong.
It may be publicity (and there may be no such thing as bad press), but
it's not favorable publicity, and it rubs a lot of people who have been
involved with Linux a long time the wrong way.
There are people who get angry at us for correcting the mistaken
picture, but in the long run it would be self-defeating (as well as
dishonorable) to bow to such pressure. See
http://www.gnu.org/gnu/gnu-linux-faq.html#alienate.
^ permalink raw reply
* [parisc-linux] Re: Generic RTC driver in 2.4.x
From: Geert Uytterhoeven @ 2003-01-12 11:33 UTC (permalink / raw)
To: Helge Deller; +Cc: Alan Cox, parisc-linux, Linux/PPC Development, Linux/m68k
In-Reply-To: <200301112050.46194.deller@gmx.de>
On Sat, 11 Jan 2003, Helge Deller wrote:
> On Friday 10 January 2003 21:05, Geert Uytterhoeven wrote:
> > Unfortunately I didn't receive any feedback from the pa-risc and ppc people
> > after my previous posting last Sunday.
>
> It took me some time, but here are the PA-RISC specific patches vs. your
> latest genrtc driver.
>
> Please consider applying,
Thanks! Applied.
I made some more changes afterwards:
- Remove unnecessary forward declaration of gen_rtc_ioctl()
- Add forward declaration for gen_rtc_interrupt()
- Remove obsolete extern declaration for gen_rtc_interrupt() on m68k
- Change `unsigned' to `unsigned int'
- Change value of RTC_BATT_BAD to 0x100 (0x10 conflicted with RTC_UIE, and
0x01 is already used in <linux/mc146818rtc.h>)
- Update m68k get_rtc_time() to return flags
BTW, perhaps we should move the global RTC_* definitions in <asm/rtc.h> to
<linux/genrtc.h>, or merge them with the ones in <linux/mc146818rtc.h> and move
them to <linux/rtc.h>?
--- linux-genrtc-parisc-2.4.20/drivers/char/genrtc.c Sun Jan 12 12:01:23 2003
+++ linux-m68k-2.4.20/drivers/char/genrtc.c Sun Jan 12 12:18:21 2003
@@ -66,8 +66,8 @@
static DECLARE_WAIT_QUEUE_HEAD(gen_rtc_wait);
-static int gen_rtc_ioctl(struct inode *inode, struct file *file,
- unsigned int cmd, unsigned long arg);
+static void gen_rtc_interrupt(unsigned long arg);
+
/*
* Bits in gen_rtc_status.
@@ -446,7 +446,7 @@
{
char *p;
struct rtc_time tm;
- unsigned flags;
+ unsigned int flags;
struct rtc_pll_info pll;
p = buf;
--- linux-genrtc-parisc-2.4.20/include/asm-parisc/rtc.h Sun Jan 12 12:01:23 2003
+++ linux-m68k-2.4.20/include/asm-parisc/rtc.h Sun Jan 12 11:05:53 2003
@@ -12,8 +12,9 @@
#define RTC_AIE 0x20 /* alarm interrupt enable */
#define RTC_UIE 0x10 /* update-finished interrupt enable */
+#define RTC_BATT_BAD 0x100 /* battery bad */
+
/* some dummy definitions */
-#define RTC_BATT_BAD 0x10 /* battery bad */
#define RTC_SQWE 0x08 /* enable square-wave output */
#define RTC_DM_BINARY 0x04 /* all time/date values are BCD if clear */
#define RTC_24H 0x02 /* 24 hour mode - else hours bit 7 means pm */
@@ -37,7 +38,7 @@
{ 0, 31, 60, 91, 121, 152, 182, 213, 244, 274, 305, 335, 366 }
};
-static inline unsigned get_rtc_time(struct rtc_time *wtime)
+static inline unsigned int get_rtc_time(struct rtc_time *wtime)
{
/*
* Only the values that we read from the RTC are set. We leave
--- linux-genrtc-parisc-2.4.20/include/asm-m68k/rtc.h Fri Jan 10 20:54:25 2003
+++ linux-m68k-2.4.20/include/asm-m68k/rtc.h Sun Jan 12 12:18:29 2003
@@ -21,15 +21,14 @@
#define RTC_AIE 0x20 /* alarm interrupt enable */
#define RTC_UIE 0x10 /* update-finished interrupt enable */
-extern void gen_rtc_interrupt(unsigned long);
-
/* some dummy definitions */
+#define RTC_BATT_BAD 0x100 /* battery bad */
#define RTC_SQWE 0x08 /* enable square-wave output */
#define RTC_DM_BINARY 0x04 /* all time/date values are BCD if clear */
#define RTC_24H 0x02 /* 24 hour mode - else hours bit 7 means pm */
#define RTC_DST_EN 0x01 /* auto switch DST - works f. USA only */
-static inline void get_rtc_time(struct rtc_time *time)
+static inline unsigned int get_rtc_time(struct rtc_time *time)
{
/*
* Only the values that we read from the RTC are set. We leave
@@ -38,6 +37,7 @@
* by the RTC when initially set to a non-zero value.
*/
mach_hwclk(0, time);
+ return RTC_24H;
}
static inline int set_rtc_time(struct rtc_time *time)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: Generic RTC driver in 2.4.x
From: Geert Uytterhoeven @ 2003-01-12 11:33 UTC (permalink / raw)
To: Helge Deller; +Cc: Alan Cox, parisc-linux, Linux/PPC Development, Linux/m68k
In-Reply-To: <200301112050.46194.deller@gmx.de>
On Sat, 11 Jan 2003, Helge Deller wrote:
> On Friday 10 January 2003 21:05, Geert Uytterhoeven wrote:
> > Unfortunately I didn't receive any feedback from the pa-risc and ppc people
> > after my previous posting last Sunday.
>
> It took me some time, but here are the PA-RISC specific patches vs. your
> latest genrtc driver.
>
> Please consider applying,
Thanks! Applied.
I made some more changes afterwards:
- Remove unnecessary forward declaration of gen_rtc_ioctl()
- Add forward declaration for gen_rtc_interrupt()
- Remove obsolete extern declaration for gen_rtc_interrupt() on m68k
- Change `unsigned' to `unsigned int'
- Change value of RTC_BATT_BAD to 0x100 (0x10 conflicted with RTC_UIE, and
0x01 is already used in <linux/mc146818rtc.h>)
- Update m68k get_rtc_time() to return flags
BTW, perhaps we should move the global RTC_* definitions in <asm/rtc.h> to
<linux/genrtc.h>, or merge them with the ones in <linux/mc146818rtc.h> and move
them to <linux/rtc.h>?
--- linux-genrtc-parisc-2.4.20/drivers/char/genrtc.c Sun Jan 12 12:01:23 2003
+++ linux-m68k-2.4.20/drivers/char/genrtc.c Sun Jan 12 12:18:21 2003
@@ -66,8 +66,8 @@
static DECLARE_WAIT_QUEUE_HEAD(gen_rtc_wait);
-static int gen_rtc_ioctl(struct inode *inode, struct file *file,
- unsigned int cmd, unsigned long arg);
+static void gen_rtc_interrupt(unsigned long arg);
+
/*
* Bits in gen_rtc_status.
@@ -446,7 +446,7 @@
{
char *p;
struct rtc_time tm;
- unsigned flags;
+ unsigned int flags;
struct rtc_pll_info pll;
p = buf;
--- linux-genrtc-parisc-2.4.20/include/asm-parisc/rtc.h Sun Jan 12 12:01:23 2003
+++ linux-m68k-2.4.20/include/asm-parisc/rtc.h Sun Jan 12 11:05:53 2003
@@ -12,8 +12,9 @@
#define RTC_AIE 0x20 /* alarm interrupt enable */
#define RTC_UIE 0x10 /* update-finished interrupt enable */
+#define RTC_BATT_BAD 0x100 /* battery bad */
+
/* some dummy definitions */
-#define RTC_BATT_BAD 0x10 /* battery bad */
#define RTC_SQWE 0x08 /* enable square-wave output */
#define RTC_DM_BINARY 0x04 /* all time/date values are BCD if clear */
#define RTC_24H 0x02 /* 24 hour mode - else hours bit 7 means pm */
@@ -37,7 +38,7 @@
{ 0, 31, 60, 91, 121, 152, 182, 213, 244, 274, 305, 335, 366 }
};
-static inline unsigned get_rtc_time(struct rtc_time *wtime)
+static inline unsigned int get_rtc_time(struct rtc_time *wtime)
{
/*
* Only the values that we read from the RTC are set. We leave
--- linux-genrtc-parisc-2.4.20/include/asm-m68k/rtc.h Fri Jan 10 20:54:25 2003
+++ linux-m68k-2.4.20/include/asm-m68k/rtc.h Sun Jan 12 12:18:29 2003
@@ -21,15 +21,14 @@
#define RTC_AIE 0x20 /* alarm interrupt enable */
#define RTC_UIE 0x10 /* update-finished interrupt enable */
-extern void gen_rtc_interrupt(unsigned long);
-
/* some dummy definitions */
+#define RTC_BATT_BAD 0x100 /* battery bad */
#define RTC_SQWE 0x08 /* enable square-wave output */
#define RTC_DM_BINARY 0x04 /* all time/date values are BCD if clear */
#define RTC_24H 0x02 /* 24 hour mode - else hours bit 7 means pm */
#define RTC_DST_EN 0x01 /* auto switch DST - works f. USA only */
-static inline void get_rtc_time(struct rtc_time *time)
+static inline unsigned int get_rtc_time(struct rtc_time *time)
{
/*
* Only the values that we read from the RTC are set. We leave
@@ -38,6 +37,7 @@
* by the RTC when initially set to a non-zero value.
*/
mach_hwclk(0, time);
+ return RTC_24H;
}
static inline int set_rtc_time(struct rtc_time *time)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* [parisc-linux] Re: Generic RTC driver in 2.4.x
From: Geert Uytterhoeven @ 2003-01-12 11:33 UTC (permalink / raw)
To: Helge Deller; +Cc: Alan Cox, parisc-linux, Linux/PPC Development, Linux/m68k
In-Reply-To: <200301112050.46194.deller@gmx.de>
On Sat, 11 Jan 2003, Helge Deller wrote:
> On Friday 10 January 2003 21:05, Geert Uytterhoeven wrote:
> > Unfortunately I didn't receive any feedback from the pa-risc and ppc people
> > after my previous posting last Sunday.
>
> It took me some time, but here are the PA-RISC specific patches vs. your
> latest genrtc driver.
>
> Please consider applying,
Thanks! Applied.
I made some more changes afterwards:
- Remove unnecessary forward declaration of gen_rtc_ioctl()
- Add forward declaration for gen_rtc_interrupt()
- Remove obsolete extern declaration for gen_rtc_interrupt() on m68k
- Change `unsigned' to `unsigned int'
- Change value of RTC_BATT_BAD to 0x100 (0x10 conflicted with RTC_UIE, and
0x01 is already used in <linux/mc146818rtc.h>)
- Update m68k get_rtc_time() to return flags
BTW, perhaps we should move the global RTC_* definitions in <asm/rtc.h> to
<linux/genrtc.h>, or merge them with the ones in <linux/mc146818rtc.h> and move
them to <linux/rtc.h>?
--- linux-genrtc-parisc-2.4.20/drivers/char/genrtc.c Sun Jan 12 12:01:23 2003
+++ linux-m68k-2.4.20/drivers/char/genrtc.c Sun Jan 12 12:18:21 2003
@@ -66,8 +66,8 @@
static DECLARE_WAIT_QUEUE_HEAD(gen_rtc_wait);
-static int gen_rtc_ioctl(struct inode *inode, struct file *file,
- unsigned int cmd, unsigned long arg);
+static void gen_rtc_interrupt(unsigned long arg);
+
/*
* Bits in gen_rtc_status.
@@ -446,7 +446,7 @@
{
char *p;
struct rtc_time tm;
- unsigned flags;
+ unsigned int flags;
struct rtc_pll_info pll;
p = buf;
--- linux-genrtc-parisc-2.4.20/include/asm-parisc/rtc.h Sun Jan 12 12:01:23 2003
+++ linux-m68k-2.4.20/include/asm-parisc/rtc.h Sun Jan 12 11:05:53 2003
@@ -12,8 +12,9 @@
#define RTC_AIE 0x20 /* alarm interrupt enable */
#define RTC_UIE 0x10 /* update-finished interrupt enable */
+#define RTC_BATT_BAD 0x100 /* battery bad */
+
/* some dummy definitions */
-#define RTC_BATT_BAD 0x10 /* battery bad */
#define RTC_SQWE 0x08 /* enable square-wave output */
#define RTC_DM_BINARY 0x04 /* all time/date values are BCD if clear */
#define RTC_24H 0x02 /* 24 hour mode - else hours bit 7 means pm */
@@ -37,7 +38,7 @@
{ 0, 31, 60, 91, 121, 152, 182, 213, 244, 274, 305, 335, 366 }
};
-static inline unsigned get_rtc_time(struct rtc_time *wtime)
+static inline unsigned int get_rtc_time(struct rtc_time *wtime)
{
/*
* Only the values that we read from the RTC are set. We leave
--- linux-genrtc-parisc-2.4.20/include/asm-m68k/rtc.h Fri Jan 10 20:54:25 2003
+++ linux-m68k-2.4.20/include/asm-m68k/rtc.h Sun Jan 12 12:18:29 2003
@@ -21,15 +21,14 @@
#define RTC_AIE 0x20 /* alarm interrupt enable */
#define RTC_UIE 0x10 /* update-finished interrupt enable */
-extern void gen_rtc_interrupt(unsigned long);
-
/* some dummy definitions */
+#define RTC_BATT_BAD 0x100 /* battery bad */
#define RTC_SQWE 0x08 /* enable square-wave output */
#define RTC_DM_BINARY 0x04 /* all time/date values are BCD if clear */
#define RTC_24H 0x02 /* 24 hour mode - else hours bit 7 means pm */
#define RTC_DST_EN 0x01 /* auto switch DST - works f. USA only */
-static inline void get_rtc_time(struct rtc_time *time)
+static inline unsigned int get_rtc_time(struct rtc_time *time)
{
/*
* Only the values that we read from the RTC are set. We leave
@@ -38,6 +37,7 @@
* by the RTC when initially set to a non-zero value.
*/
mach_hwclk(0, time);
+ return RTC_24H;
}
static inline int set_rtc_time(struct rtc_time *time)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 2.5.56] cpufreq not compiling without /proc
From: Paul Rolland @ 2003-01-12 11:38 UTC (permalink / raw)
To: linux-kernel, 'Dominik Brodowski'; +Cc: rol
Hello,
This is a quick patch to ensure that functions used to create
and remove entries in /proc are not compiled in support for /proc
is not enabled.
Regards,
Paul Rolland, rol@as2917.net
--- linux-2.5.56/net/ipv4/route.c 2003-01-10 21:12:25.000000000
+0100
+++ linux-2.5.56-work/net/ipv4/route.c 2003-01-12 12:11:30.000000000
+0100
@@ -2672,12 +2672,14 @@
ip_rt_gc_interval;
add_timer(&rt_periodic_timer);
+#ifdef CONFIG_PROC_FS
if (rt_cache_proc_init())
goto out_enomem;
proc_net_create ("rt_cache_stat", 0, rt_cache_stat_get_info);
#ifdef CONFIG_NET_CLS_ROUTE
create_proc_read_entry("net/rt_acct", 0, 0, ip_rt_acct_read,
NULL);
#endif
+#endif
xfrm_init();
out:
return rc;
^ permalink raw reply
* Re: Generic RTC driver in 2.4.x (fwd)
From: Geert Uytterhoeven @ 2003-01-12 11:29 UTC (permalink / raw)
To: Linux/PPC Development
[-- Attachment #1: Type: TEXT/PLAIN, Size: 993 bytes --]
FYI...
---------- Forwarded message ----------
Date: Sat, 11 Jan 2003 20:50:46 +0100
From: Helge Deller <deller@gmx.de>
To: Geert Uytterhoeven <geert@linux-m68k.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>, parisc-linux@parisc-linux.org
Cc: Linux/m68k <linux-m68k@lists.linux-m68k.org>
Subject: Re: Generic RTC driver in 2.4.x
On Friday 10 January 2003 21:05, Geert Uytterhoeven wrote:
> Unfortunately I didn't receive any feedback from the pa-risc and ppc people
> after my previous posting last Sunday.
Hi Geert,
It took me some time, but here are the PA-RISC specific patches vs. your
latest genrtc driver.
Please consider applying,
Helge
ChangeLog:
- small indenting fixes,
- new driver version number
- more "static" functions
- C99 named initializers
- added RTC_BATT_BAD capatibility flag (for the procfs-interface),
- get_rtc_time() now returns the "capatibilities" value (e.g. RTC_BATT_BAD | RTC_24H)
[this means, the m86k get_rtc_time() function has to return a value too.
[-- Attachment #2: Type: TEXT/PLAIN, Size: 8880 bytes --]
--- ./drivers/char/genrtc.c.geert Sat Jan 11 18:14:50 2003
+++ ./drivers/char/genrtc.c Sat Jan 11 20:36:28 2003
@@ -1,5 +1,8 @@
/*
- * Real Time Clock interface for q40 and other m68k machines
+ * Real Time Clock interface for
+ * - q40 and other m68k machines,
+ * - HP PARISC machines
+ * - PowerPC machines
* emulate some RTC irq capabilities in software
*
* Copyright (C) 1999 Richard Zidlicky
@@ -13,7 +16,7 @@
* pseudo-file for status information.
*
* The ioctls can be used to set the interrupt behaviour where
- * supported.
+ * supported.
*
* The /dev/rtc interface will block on reads until an interrupt
* has been received. If a RTC interrupt has already happened,
@@ -34,9 +37,10 @@
* 1.04 removed useless timer code rz@linux-m68k.org
* 1.05 portable RTC_UIE emulation rz@linux-m68k.org
* 1.06 set_rtc_time can return an error trini@kernel.crashing.org
+ * 1.07 ported to HP PARISC (hppa) Helge Deller <deller@gmx.de>
*/
-#define RTC_VERSION "1.06"
+#define RTC_VERSION "1.07"
#include <linux/module.h>
#include <linux/config.h>
@@ -71,11 +75,11 @@
#define RTC_IS_OPEN 0x01 /* means /dev/rtc is in use */
-unsigned char gen_rtc_status; /* bitmapped status byte. */
-unsigned long gen_rtc_irq_data; /* our output to the world */
+static unsigned char gen_rtc_status; /* bitmapped status byte. */
+static unsigned long gen_rtc_irq_data; /* our output to the world */
/* months start at 0 now */
-unsigned char days_in_mo[] =
+static unsigned char days_in_mo[] =
{31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31};
static int irq_active;
@@ -88,7 +92,7 @@
static int lostint;
static int tt_exp;
-void gen_rtc_timer(unsigned long data);
+static void gen_rtc_timer(unsigned long data);
static volatile int stask_active; /* schedule_task */
static volatile int ttask_active; /* timer_task */
@@ -99,7 +103,7 @@
* Routine to poll RTC seconds field for change as often as posible,
* after first RTC_UIE use timer to reduce polling
*/
-void genrtc_troutine(void *data)
+static void genrtc_troutine(void *data)
{
unsigned int tmp = get_rtc_ss();
@@ -123,7 +127,7 @@
stask_active = 0;
}
-void gen_rtc_timer(unsigned long data)
+static void gen_rtc_timer(unsigned long data)
{
lostint = get_rtc_ss() - oldsecs ;
if (lostint<0)
@@ -144,7 +148,7 @@
* from some routine that periodically (eg 100HZ) monitors
* whether RTC_SECS changed
*/
-void gen_rtc_interrupt(unsigned long arg)
+static void gen_rtc_interrupt(unsigned long arg)
{
/* We store the status in the low byte and the number of
* interrupts received since the last read in the remainder
@@ -384,24 +388,24 @@
*/
static struct file_operations gen_rtc_fops = {
- owner: THIS_MODULE,
+ .owner = THIS_MODULE,
#ifdef CONFIG_GEN_RTC_X
- read: gen_rtc_read,
- poll: gen_rtc_poll,
+ .read = gen_rtc_read,
+ .poll = gen_rtc_poll,
#endif
- ioctl: gen_rtc_ioctl,
- open: gen_rtc_open,
- release: gen_rtc_release
+ .ioctl = gen_rtc_ioctl,
+ .open = gen_rtc_open,
+ .release = gen_rtc_release,
};
static struct miscdevice rtc_gen_dev =
{
- RTC_MINOR,
- "rtc",
- &gen_rtc_fops
+ .minor = RTC_MINOR,
+ .name = "rtc",
+ .fops = &gen_rtc_fops,
};
-int __init rtc_generic_init(void)
+static int __init rtc_generic_init(void)
{
int retval;
@@ -436,16 +440,18 @@
* Info exported via "/proc/rtc".
*/
-int gen_rtc_proc_output(char *buf)
+#ifdef CONFIG_PROC_FS
+
+static int gen_rtc_proc_output(char *buf)
{
char *p;
struct rtc_time tm;
- unsigned tmp;
+ unsigned flags;
struct rtc_pll_info pll;
p = buf;
- get_rtc_time(&tm);
+ flags = get_rtc_time(&tm);
p += sprintf(p,
"rtc_time\t: %02d:%02d:%02d\n"
@@ -454,7 +460,7 @@
tm.tm_hour, tm.tm_min, tm.tm_sec,
tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday, 1900);
- tm.tm_hour=0;tm.tm_min=0;tm.tm_sec=0;
+ tm.tm_hour = tm.tm_min = tm.tm_sec = 0;
p += sprintf(p, "alarm\t\t: ");
if (tm.tm_hour <= 24)
@@ -472,7 +478,6 @@
else
p += sprintf(p, "**\n");
- tmp= RTC_24H ;
p += sprintf(p,
"DST_enable\t: %s\n"
"BCD\t\t: %s\n"
@@ -483,15 +488,15 @@
"periodic_IRQ\t: %s\n"
"periodic_freq\t: %ld\n"
"batt_status\t: %s\n",
- (tmp & RTC_DST_EN) ? "yes" : "no",
- (tmp & RTC_DM_BINARY) ? "no" : "yes",
- (tmp & RTC_24H) ? "yes" : "no",
- (tmp & RTC_SQWE) ? "yes" : "no",
- (tmp & RTC_AIE) ? "yes" : "no",
+ (flags & RTC_DST_EN) ? "yes" : "no",
+ (flags & RTC_DM_BINARY) ? "no" : "yes",
+ (flags & RTC_24H) ? "yes" : "no",
+ (flags & RTC_SQWE) ? "yes" : "no",
+ (flags & RTC_AIE) ? "yes" : "no",
irq_active ? "yes" : "no",
- (tmp & RTC_PIE) ? "yes" : "no",
+ (flags & RTC_PIE) ? "yes" : "no",
0L /* freq */,
- "okay" );
+ (flags & RTC_BATT_BAD) ? "bad" : "okay");
if (!get_rtc_pll(&pll))
p += sprintf(p,
"PLL adjustment\t: %d\n"
@@ -506,7 +511,7 @@
pll.pll_posmult,
pll.pll_negmult,
pll.pll_clock);
- return p - buf;
+ return p - buf;
}
static int gen_rtc_read_proc(char *page, char **start, off_t off,
@@ -521,6 +526,8 @@
return len;
}
+#endif /* CONFIG_PROC_FS */
+
MODULE_AUTHOR("Richard Zidlicky");
MODULE_LICENSE("GPL");
--- ./include/asm-parisc/rtc.h.geert Sat Jan 11 18:21:25 2003
+++ ./include/asm-parisc/rtc.h Sat Jan 11 20:40:41 2003
@@ -0,0 +1,131 @@
+/* include/asm-parisc/rtc.h */
+
+#ifndef _ASM_RTC_H
+#define _ASM_RTC_H
+
+#ifdef __KERNEL__
+
+#include <linux/rtc.h>
+#include <asm/errno.h>
+
+#define RTC_PIE 0x40 /* periodic interrupt enable */
+#define RTC_AIE 0x20 /* alarm interrupt enable */
+#define RTC_UIE 0x10 /* update-finished interrupt enable */
+
+/* some dummy definitions */
+#define RTC_BATT_BAD 0x10 /* battery bad */
+#define RTC_SQWE 0x08 /* enable square-wave output */
+#define RTC_DM_BINARY 0x04 /* all time/date values are BCD if clear */
+#define RTC_24H 0x02 /* 24 hour mode - else hours bit 7 means pm */
+#define RTC_DST_EN 0x01 /* auto switch DST - works f. USA only */
+
+
+/* constants for calculation */
+#define SECS_PER_HOUR (60 * 60)
+#define SECS_PER_DAY (SECS_PER_HOUR * 24)
+
+#define __isleap(year) \
+ ((year) % 4 == 0 && ((year) % 100 != 0 || (year) % 400 == 0))
+
+
+/* How many days come before each month (0-12). */
+static const unsigned short int __mon_yday[2][13] =
+{
+ /* Normal years. */
+ { 0, 31, 59, 90, 120, 151, 181, 212, 243, 273, 304, 334, 365 },
+ /* Leap years. */
+ { 0, 31, 60, 91, 121, 152, 182, 213, 244, 274, 305, 335, 366 }
+};
+
+static inline unsigned get_rtc_time(struct rtc_time *wtime)
+{
+ /*
+ * Only the values that we read from the RTC are set. We leave
+ * tm_wday, tm_yday and tm_isdst untouched. Even though the
+ * RTC has RTC_DAY_OF_WEEK, we ignore it, as it is only updated
+ * by the RTC when initially set to a non-zero value.
+ */
+
+ struct pdc_tod tod_data;
+ long int days, rem, y;
+ const unsigned short int *ip;
+
+ if (pdc_tod_read(&tod_data) < 0)
+ return (RTC_24H | RTC_BATT_BAD);
+
+
+ // most of the remainder of this function is:
+ // Copyright (C) 1991, 1993, 1997, 1998 Free Software Foundation, Inc.
+ // This was originally a part of the GNU C Library.
+ // It is distributed under the GPL, and was swiped from offtime.c
+
+
+ days = tod_data.tod_sec / SECS_PER_DAY;
+ rem = tod_data.tod_sec % SECS_PER_DAY;
+
+ wtime->tm_hour = rem / SECS_PER_HOUR;
+ rem %= SECS_PER_HOUR;
+ wtime->tm_min = rem / 60;
+ wtime->tm_sec = rem % 60;
+
+ y = 1970;
+
+#define DIV(a, b) ((a) / (b) - ((a) % (b) < 0))
+#define LEAPS_THRU_END_OF(y) (DIV (y, 4) - DIV (y, 100) + DIV (y, 400))
+
+ while (days < 0 || days >= (__isleap (y) ? 366 : 365))
+ {
+ /* Guess a corrected year, assuming 365 days per year. */
+ long int yg = y + days / 365 - (days % 365 < 0);
+
+ /* Adjust DAYS and Y to match the guessed year. */
+ days -= ((yg - y) * 365
+ + LEAPS_THRU_END_OF (yg - 1)
+ - LEAPS_THRU_END_OF (y - 1));
+ y = yg;
+ }
+ wtime->tm_year = y - 1900;
+#undef DIV
+#undef LEAPS_THRU_END_OF
+
+ ip = __mon_yday[__isleap(y)];
+ for (y = 11; days < (long int) ip[y]; --y)
+ continue;
+ days -= ip[y];
+ wtime->tm_mon = y;
+ wtime->tm_mday = days + 1;
+
+ return (RTC_24H);
+}
+
+static inline int set_rtc_time(struct rtc_time *wtime)
+{
+ u_int32_t secs;
+
+ secs = mktime(wtime->tm_year + 1900, wtime->tm_mon + 1, wtime->tm_mday,
+ wtime->tm_hour, wtime->tm_min, wtime->tm_sec);
+
+ if (pdc_tod_set(secs, 0) < 0)
+ return -EINVAL;
+ else
+ return 0;
+}
+
+static inline unsigned int get_rtc_ss(void)
+{
+ return -EINVAL;
+}
+
+static inline int get_rtc_pll(struct rtc_pll_info *pll)
+{
+ return -EINVAL;
+}
+static inline int set_rtc_pll(struct rtc_pll_info *pll)
+{
+ return -EINVAL;
+}
+
+#endif /* __KERNEL__ */
+
+#endif /* _ASM__RTC_H */
+
^ permalink raw reply
* Re: fonts
From: Geert Uytterhoeven @ 2003-01-12 11:25 UTC (permalink / raw)
To: Antonino Daplas; +Cc: Linux Frame Buffer Device Development
In-Reply-To: <1042366917.1016.9.camel@localhost.localdomain>
On 12 Jan 2003, Antonino Daplas wrote:
> On Sun, 2003-01-12 at 03:15, Geert Uytterhoeven wrote:
> > I'm trying out different fonts with amifb (based on 2.5.56 from Linus).
> > - PEARL8x8: OK
> > - SUN12x22: garbage (random characters)
> > - ProFont6x11: garbage (each different line is filled with a different
> > character)
> > - MINI4x6: garbage (each different line is filled with a different
> > character)
> >
> > At first I thought it may be caused by xres and yres not divisible by the
> > fontsize, so I tried a 800x600 mode with MINI4x6. But the problem stayed the
> > same, except that only a 640x600 window in the right part of the screen was
> > used.
> >
> > Is my planar code in amifb to blane, or have other people seen the same?
> >
>
> The cfb_imageblit() function exhibited the same behavior. I think we
> both made the wrong assumption that all monochrome bitmaps are packed. I
> think the rule is:
>
> The first pixel on the next scanline is always at the next byte from
> the last pixel of the current scanline.
>
> So a 12x22 font has 16 bits per scanline but only 12 are usable, and the
> last 4 are used as padding. It's worse with a 4x6 fonts where the
> 4-bits are just duplicated in the other nibble.
Yes.
But that was not my problem. Currently accel_putcs() falls back to individual
character drawing if the fontwidth is not a multiple of 8, and reuses the same
struct fb_image for each call of fb_imageblit(). And since my fb_imageblit()
had a loop like `while (image->height--) { ... }' it failed. Not modifying the
passed struct fb_image fixed the problem. Yes, we need the const there :-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: [linux-lvm] [Q] LVM snapshot volume extendable?
From: jon+lvm @ 2003-01-12 11:16 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <01be01c2ba3e$b188b3a0$0f00a8c0@COMPAQ>
On Sun, Jan 12, 2003 at 10:29:54PM +0900, Sean Oh wrote:
[cut]
Would you be so kind to reply inbetween the text, as i did, or below (if
it's not that much text)
and while you are at it, cut the unneeeded lines out. You left all my
text intact, which was 70 useless lines.
JonB
^ permalink raw reply
* Re: [PATCH] sd.c
From: Andries.Brouwer @ 2003-01-12 11:20 UTC (permalink / raw)
To: Andries.Brouwer, zaitcev; +Cc: linux-kernel
> + /*
> + * If manual intervention is required, or this is an
> + * absent USB storage device, a spinup is meaningless.
> + */
> + if (SRpnt->sr_sense_buffer[2] == NOT_READY &&
> + SRpnt->sr_sense_buffer[12] == 4 /* not ready */ &&
> + SRpnt->sr_sense_buffer[13] == 3)
Why is this not inside media_not_present?
It is bad to have a routine do something other than its name says.
I wrote media_not_present() and made it test for precisely that:
3A: medium not present.
Here we have "not ready, manual intervention required".
There are so many different SCSI devices - there might well be some
where the reason for the need of manual intervention is different.
And indeed our usb-storage code synthesizes this for the case
where the device (rather than the media) is absent.
> + * sd_read_cache_type - called only from sd_init_onedisk()
Was it necessary to move and change sd_read_cache_type
simultaneously? Makes a joke of the diff.
It calls sd_do_mode_sense6, so if sd_read_cache_type was
not moved we would had to add a prototype of sd_do_mode_sense6.
Moreover, this was the right place.
Sooner or later we'll want to merge it with the routine before.
> + /* without media there is no reason to ask;
> + moreover, some devices react badly if we do */
> + if (sdkp->media_present)
> + sd_read_cache_type(sdkp, disk->disk_name, SRpnt, buffer);
Hmm... cautiously ok.
-- Pete
Andries
Now that I reply anyway, let me store some of my waste paper in the
net archives, before throwing it away.
(i) The DBD bit is there for completeness, but not because it is
needed. I know of no devices that need it or that react badly to it.
(ii) The Imation FlashGo! returns Not Ready, Medium not present
without card, and 03 00 00 08 in sd_read_cache_type() with DBD bit,
and 0B 00 00 08 00 00 3D FF 00 00 02 00 without DBD bit,
when fed with an 8 MB CF card. This shows that if one asks for a mode
page that the device does not have, where most devices will reply
Illegal Request - Invalid Field in parameter list (or: in CDB),
some devices just return zero bytes following the header.
^ permalink raw reply
* Laptop ahoy!
From: Richard Wallman @ 2003-01-12 11:10 UTC (permalink / raw)
To: Linux 8086
Have just obtained a Texas Instruments TravelMate 2000 laptop:
12MHz 286 CPU
3MB of RAM
20Mb hard disk
BW LCD screen
Needless to say, this is ELKS fodder. :)
How's the bcc port to ELKS going? If I can get a compiler system
running on this laptop, it means my own projects can get done a Hell of
a lot faster!
Anyone know where I can get technical details/manuals for this thing?
I've tried Google, and I know if I ever need a battery for it I'll be
alright! ;)
--
Richard Wallman
http://www.murkygoth.uklinux.net/elks
^ permalink raw reply
* [PATCH 2.5.56] net/ipv4/route.c doesn't compile without /proc support
From: Paul Rolland @ 2003-01-12 11:18 UTC (permalink / raw)
To: davem, kuznet, linux-kernel; +Cc: rol
Hello,
Here is a quick patch to allow correct compile of net/ipv4/route.c
when not using /proc support.
Without it, some attempts to create entries in /proc are resulting
in invoking functions that are protected by #ifdef CONFIG_PROC_FS...
Regards,
Paul Rolland, rol@as2917.net
--- linux-2.5.56/net/ipv4/route.c 2003-01-10 21:12:25.000000000
+0100
+++ linux-2.5.56-work/net/ipv4/route.c 2003-01-12 12:11:30.000000000
+0100
@@ -2672,12 +2672,14 @@
ip_rt_gc_interval;
add_timer(&rt_periodic_timer);
+#ifdef CONFIG_PROC_FS
if (rt_cache_proc_init())
goto out_enomem;
proc_net_create ("rt_cache_stat", 0, rt_cache_stat_get_info);
#ifdef CONFIG_NET_CLS_ROUTE
create_proc_read_entry("net/rt_acct", 0, 0, ip_rt_acct_read,
NULL);
#endif
+#endif
xfrm_init();
out:
return rc;
^ permalink raw reply
* Re: dell precision m50 _very_ slow paging/swapping
From: Andrew McGregor @ 2003-01-12 11:09 UTC (permalink / raw)
To: Andrew Morton, Roe Peterson, linux-laptop, linux-kernel
In-Reply-To: <200301111012.55150.akpm@digeo.com>
Have you tried hdparm to see if the disk is in a stupid mode and needs
something (DMA most likely) switched on to perform? Dell BIOSes often get
this wrong. idebus=66 on the kernel command line is appropriate too.
Andrew
--On Saturday, January 11, 2003 10:12:55 -0800 Andrew Morton
<akpm@digeo.com> wrote:
> On Sat January 11 2003 07:37, Roe Peterson wrote:
>>
>> Although Dell doesn't consider the precision M50 a laptop (it's a
>> "portable workstation"), this list
>> looks like a good place to start :-)
>>
>> I'm having a big problem with a brand-new M50. The symptoms persist
>> whether I try Redhat 7.3
>> or 8.0.
>>
>> Generally, everything is fine, right up to the time the machine starts
>> paging out to disk. Then, the
>> system essentially grinds to a halt.
>>
>
> You'd need to determine whether the CPU is busy or idle when this is
> happening.
>
> If it's busy, profile the kernel:
>
> - boot with "profile=1" on the kernel command line
>
> -
> readprofile -r
> <do something>
> readprofile -v -m /boot/System.map | sort -n +2 | tail -40
>
> It it's not busy, then:
>
> while true
> do
> ps axl | grep ' D '
> sleep 1
> done &
> <do something>
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
^ permalink raw reply
* ACPI 20030109 breaks kernel compile
From: Margit Schubert-While @ 2003-01-12 11:06 UTC (permalink / raw)
To: Grover, Andrew; +Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Hi,
Sorry, seems to be a seperate maintainer for this
Margit
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: Nvidia and its choice to read the GPL "differently"
From: Andrew McGregor @ 2003-01-12 11:13 UTC (permalink / raw)
To: robw, Vojtech Pavlik; +Cc: Kurt Garloff, Linux kernel list
In-Reply-To: <1042325870.1034.45.camel@RobsPC.RobertWilkens.com>
--On Saturday, January 11, 2003 17:57:50 -0500 Rob Wilkens
<robw@optonline.net> wrote:
> [Pushing the NVIDIA thread further because I have one of these damned
> cards and want support for it in the 2.5+ kernels.]
The canonical place to look for this is www.minion.de
Andrew
^ permalink raw reply
* Re: any chance of 2.6.0-test*?
From: Horst von Brand @ 2003-01-11 20:10 UTC (permalink / raw)
To: Shawn Starr; +Cc: Linux Kernel Mailing List
In-Reply-To: <200301101139.57342.shawn.starr@datawire.net>
Shawn Starr <shawn.starr@datawire.net> said:
> There will be a new kernel tree that will fit this purpose soon called
> -xlk (eXtendable or Extended Linux Kernel). The hope to make it an
> 'official' like -ac, -mm tree for stuffing experimental stuff into a post
> 2.6 (or just before 2.6 goes live) kernel. I will need help in getting
> this to become a reality in the coming months to 2.6.
Thanks, but please don't. The idea of the feature/code freezes, and then
the stable version running alone for a while, is precisely to focus the
hacker comunity on fixing the bugs and cleaning up, and then stabilizing
the whole. Please don't distract them.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: [parisc-linux] upgrading kernel
From: Peter Lavender @ 2003-01-12 11:02 UTC (permalink / raw)
To: parisc
In-Reply-To: <20030112073506.GB1177@tausq.org>
* Randolph Chung (randolph@tausq.org) wrote:
> > Is upgrading the kernel for a stable system the same as for i386? I
> > haven't done this with debian before.. but I'm sure there's something
> > debian about doing it.. :)
> >
> > I'll find the relevant doco.. just want to know if it's the same for
> > the HPPA stuff.
>
> Check out the "Kernel installation" section of the parisc linux boot
> howto
>
> http://pateam.esiee.fr/parisc-linux-boot/PA-RISC-Linux-Boot-HOWTO/kernelinstall.html
Thanks... this outlines what to do with a custom kernel.. I was
thinking there might be a debian way... like with kernel-packages (I
just reading up about it now for my i386 based system).
The kernel on the 715/64 is from last year sometime ago... I can get
the kernel version with uname becuase it seg faults.
Pete
:wq
^ permalink raw reply
* Re: kconfig (gkc) [PATCH]
From: Romain Lievin @ 2003-01-12 11:00 UTC (permalink / raw)
To: Roman Zippel; +Cc: Linux Kernel
In-Reply-To: <3E1441B5.AB9A55C3@linux-m68k.org>
Hi Roman,
On Thu, Jan 02, 2003 at 02:42:13PM +0100, Roman Zippel wrote:
> Hi,
>
> Sorry about the delay, I wanted to look into this in more detail, but I
> did some other stuff over christmas.
>
me, too. I recently switched from 33.6K modem to 128kbit ADSL and I had some
work on my new gateway...
> If you can work around it and it doesn't look that serious, I would
> really prefer to support at least 2.0. I don't know how long it will
> take until all distribution switched to 2.2.
You're right, my Debian does not have 2.2 yet....
Well, I switched to 2.0 given that I can easily work around it. Nevertheless,
I placed a #define for people who want to use 2.2 release.
> BTW how are the other views doing? :)
I have just finished the 'Single' view. I am working on the 'Split' one.
>
> bye, Roman
>
>
PS: you will find the latest patch at the usual location...
Romain.
--
Romain Lievin, aka 'roms' <roms@tilp.info>
The TiLP project is on <http://www.ti-lpg.org>
"Linux, y'a moins bien mais c'est plus cher !"
^ permalink raw reply
* ACPI 20030109 + Kernel 2.4.21-pre3
From: Margit Schubert-While @ 2003-01-12 10:35 UTC (permalink / raw)
To: t-kouchi-f7IHDacdhdx8UrSeD/g0lQ
Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Hi,
Compile fail.
Margit
acpiphp_glue.c:233: parse error before '*' token
acpiphp_glue.c:234: warning: function declaration isn't a prototype
acpiphp_glue.c: In function `decode_acpi_resource':
acpiphp_glue.c:235: `acpi_resource_address16' undeclared (first use in this
function)
acpiphp_glue.c:235: (Each undeclared identifier is reported only once
acpiphp_glue.c:235: for each function it appears in.)
acpiphp_glue.c:235: `address16_data' undeclared (first use in this function)
acpiphp_glue.c:236: `acpi_resource_address32' undeclared (first use in this
function)
acpiphp_glue.c:236: `address32_data' undeclared (first use in this function)
acpiphp_glue.c:237: `acpi_resource_address64' undeclared (first use in this
function)
acpiphp_glue.c:237: `address64_data' undeclared (first use in this function)
acpiphp_glue.c:253: `resource' undeclared (first use in this function)
acpiphp_glue.c:255: parse error before ')' token
acpiphp_glue.c:267: parse error before ')' token
acpiphp_glue.c:279: parse error before ')' token
acpiphp_glue.c:299: `acpi_resource' undeclared (first use in this function)
acpiphp_glue.c:299: parse error before ')' token
acpiphp_glue.c:312: `bridge' undeclared (first use in this function)
acpiphp_glue.c: In function `decode_hpp':
acpiphp_glue.c:395: `acpi_buffer' undeclared (first use in this function)
acpiphp_glue.c:395: parse error before "buffer"
acpiphp_glue.c:398: `acpi_object' undeclared (first use in this function)
acpiphp_glue.c:398: `package' undeclared (first use in this function)
acpiphp_glue.c:420: `buffer' undeclared (first use in this function)
acpiphp_glue.c:428: parse error before ')' token
acpiphp_glue.c: In function `add_host_bridge':
acpiphp_glue.c:500: `acpi_buffer' undeclared (first use in this function)
acpiphp_glue.c:500: parse error before "buffer"
acpiphp_glue.c:538: `buffer' undeclared (first use in this function)
acpiphp_glue.c: In function `find_host_bridge':
acpiphp_glue.c:810: `acpi_device_info' undeclared (first use in this function)
acpiphp_glue.c:810: parse error before "info"
acpiphp_glue.c:812: `acpi_buffer' undeclared (first use in this function)
acpiphp_glue.c:812: parse error before "buffer"
acpiphp_glue.c:815: `info' undeclared (first use in this function)
acpiphp_glue.c:827: `buffer' undeclared (first use in this function)
acpiphp_glue.c: In function `power_off_slot':
acpiphp_glue.c:875: `acpi_object_list' undeclared (first use in this function)
acpiphp_glue.c:875: parse error before "arg_list"
acpiphp_glue.c:876: `acpi_object' undeclared (first use in this function)
acpiphp_glue.c:907: `arg_list' undeclared (first use in this function)
acpiphp_glue.c:908: `arg' undeclared (first use in this function)
acpiphp_glue.c: In function `handle_hotplug_event_bridge':
acpiphp_glue.c:1104: `acpi_buffer' undeclared (first use in this function)
acpiphp_glue.c:1104: parse error before "buffer"
acpiphp_glue.c:1109: `buffer' undeclared (first use in this function)
acpiphp_glue.c: In function `handle_hotplug_event_func':
acpiphp_glue.c:1155: `acpi_buffer' undeclared (first use in this function)
acpiphp_glue.c:1155: parse error before "buffer"
acpiphp_glue.c:1158: `buffer' undeclared (first use in this function)
make[2]: *** [acpiphp_glue.o] Error 1
make[2]: Leaving directory `/usr/linux-2.4.21/drivers/hotplug'
make[1]: *** [_modsubdir_hotplug] Error 2
make[1]: Leaving directory `/usr/linux-2.4.21/drivers'
make: *** [_mod_drivers] Error 2
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: fonts
From: Antonino Daplas @ 2003-01-12 10:26 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux Frame Buffer Device Development
In-Reply-To: <Pine.GSO.4.21.0301112010020.18673-100000@vervain.sonytel.be>
On Sun, 2003-01-12 at 03:15, Geert Uytterhoeven wrote:
>
> I'm trying out different fonts with amifb (based on 2.5.56 from Linus).
> - PEARL8x8: OK
> - SUN12x22: garbage (random characters)
> - ProFont6x11: garbage (each different line is filled with a different
> character)
> - MINI4x6: garbage (each different line is filled with a different
> character)
>
> At first I thought it may be caused by xres and yres not divisible by the
> fontsize, so I tried a 800x600 mode with MINI4x6. But the problem stayed the
> same, except that only a 640x600 window in the right part of the screen was
> used.
>
> Is my planar code in amifb to blane, or have other people seen the same?
>
The cfb_imageblit() function exhibited the same behavior. I think we
both made the wrong assumption that all monochrome bitmaps are packed. I
think the rule is:
The first pixel on the next scanline is always at the next byte from
the last pixel of the current scanline.
So a 12x22 font has 16 bits per scanline but only 12 are usable, and the
last 4 are used as padding. It's worse with a 4x6 fonts where the
4-bits are just duplicated in the other nibble.
It's a simple fix for imageblit. So here's a patch.
a. Fix for slow_imageblit() so fonts with widths not a multiple of 8
will work.
b. Fixed fast_imageblit() so it always access tables as 32-bit for it to
to work with a 64-bit machine.
James, can you apply?
Tony
diff -Naur linux-2.5.54/drivers/video/cfbimgblt.c linux/drivers/video/cfbimgblt.c
--- linux-2.5.54/drivers/video/cfbimgblt.c 2003-01-12 09:48:47.000000000 +0000
+++ linux/drivers/video/cfbimgblt.c 2003-01-12 10:06:59.000000000 +0000
@@ -88,11 +88,13 @@
#if defined (__BIG_ENDIAN)
#define LEFT_POS(bpp) (BITS_PER_LONG - bpp)
+#define LEFT_POS32(bpp) (32 - bpp)
#define NEXT_POS(pos, bpp) ((pos) -= (bpp))
#define SHIFT_HIGH(val, bits) ((val) >> (bits))
#define SHIFT_LOW(val, bits) ((val) << (bits))
#else
#define LEFT_POS(bpp) (0)
+#define LEFT_POS32(bpp) (0)
#define NEXT_POS(pos, bpp) ((pos) += (bpp))
#define SHIFT_HIGH(val, bits) ((val) << (bits))
#define SHIFT_LOW(val, bits) ((val) >> (bits))
@@ -161,7 +163,7 @@
unsigned long fgcolor, unsigned long bgcolor,
unsigned long start_index, unsigned long pitch_index)
{
- unsigned long i, j, l = 8;
+ unsigned long i, j, l;
unsigned long shift, color, bpp = p->var.bits_per_pixel;
unsigned long *dst, *dst2, val, pitch = p->fix.line_length;
unsigned long null_bits = BITS_PER_LONG - bpp;
@@ -170,10 +172,11 @@
dst2 = (unsigned long *) dst1;
for (i = image->height; i--; ) {
- shift = 0;
- val = 0;
+ shift = val = 0;
+ l = 8;
j = image->width;
dst = (unsigned long *) dst1;
+ s = src;
/* write leading bits */
if (start_index) {
@@ -182,35 +185,33 @@
val = FB_READL(dst) & start_mask;
shift = start_index;
}
+
while (j--) {
l--;
- if (*src & (1 << l))
- color = fgcolor;
- else
- color = bgcolor;
+ color = (*s & (1 << l)) ? fgcolor : bgcolor;
color <<= LEFT_POS(bpp);
val |= SHIFT_HIGH(color, shift);
/* Did the bitshift spill bits to the next long? */
if (shift >= null_bits) {
FB_WRITEL(val, dst++);
- if (shift == null_bits)
- val = 0;
- else
- val = SHIFT_LOW(color, BITS_PER_LONG - shift);
+ val = (shift == null_bits) ?
+ 0 : SHIFT_LOW(color, BITS_PER_LONG - shift);
}
shift += bpp;
shift &= (BITS_PER_LONG - 1);
- if (!l) { l = 8; src++; };
+ if (!l) { l = 8; s++; };
}
+
/* write trailing bits */
if (shift) {
unsigned long end_mask = SHIFT_HIGH(~0UL, shift);
FB_WRITEL((FB_READL(dst) & end_mask) | val, dst);
}
- dst1 += pitch;
+ dst1 += pitch;
+ src += (image->width + 7)/8;
if (pitch_index) {
dst2 += pitch;
dst1 = (char *) dst2;
@@ -224,25 +225,25 @@
}
static inline void fast_imageblit(struct fb_image *image, struct fb_info *p, u8 *dst1,
- unsigned long fgcolor, unsigned long bgcolor)
+ u32 fgcolor, u32 bgcolor)
{
int i, j, k, l = 8, n;
- unsigned long bit_mask, end_mask, eorx;
- unsigned long fgx = fgcolor, bgx = bgcolor, pad, bpp = p->var.bits_per_pixel;
- unsigned long tmp = (1 << bpp) - 1;
- unsigned long ppw = BITS_PER_LONG/bpp, ppos;
- unsigned long *dst;
+ u32 bit_mask, end_mask, eorx;
+ u32 fgx = fgcolor, bgx = bgcolor, pad, bpp = p->var.bits_per_pixel;
+ u32 tmp = (1 << bpp) - 1;
+ u32 ppw = 32/bpp, ppos;
+ u32 *dst;
u32 *tab = NULL;
char *src = image->data;
- switch (ppw) {
- case 4:
+ switch (bpp) {
+ case 8:
tab = cfb_tab8;
break;
- case 2:
+ case 16:
tab = cfb_tab16;
break;
- case 1:
+ case 32:
tab = cfb_tab32;
break;
}
@@ -264,17 +265,17 @@
k = image->width/ppw;
for (i = image->height; i--; ) {
- dst = (unsigned long *) dst1;
-
+ dst = (u32 *) dst1;
for (j = k; j--; ) {
l -= ppw;
end_mask = tab[(*src >> l) & bit_mask];
- FB_WRITEL((end_mask & eorx)^bgx, dst++);
+ fb_writel((end_mask & eorx)^bgx, dst++);
if (!l) { l = 8; src++; }
}
+
if (n) {
end_mask = 0;
- ppos = LEFT_POS(bpp);
+ ppos = LEFT_POS32(bpp);
for (j = n; j > 0; j--) {
l--;
if (*src & (1 << l))
@@ -282,9 +283,9 @@
NEXT_POS(ppos, bpp);
if (!l) { l = 8; src++; }
}
- FB_WRITEL((end_mask & eorx)^bgx, dst++);
+ fb_writel((end_mask & eorx)^bgx, dst++);
}
- l -= pad;
+ l -= pad;
dst1 += p->fix.line_length;
}
}
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: 4 port serial card.
From: JACrux @ 2003-01-12 10:34 UTC (permalink / raw)
To: Ray Wells, linux-hams
In-Reply-To: <3E20FF68.000003.11949@gizmo>
I have a similar card but the doc with it does not mention Linux - or anything
else. I got it to work by editing the setserial file to tell Linux what to do
(addresses and irqs) with the four ports. But to make it work I had to
disable all the standard serial ports in the BIOS so that the new card would
not generate conflicts. I'm still using the same card - using the BIOS
comport disabling strategy under Win 98, sorry about that. Of course as you
probably have a more modern machine, it might all be different.
John Crux G3JAG
On Sunday 12 January 2003 05:38, Ray Wells wrote:
> Hi All,
>
> This enquiry relates to a four-port serial card for a Linux BBS so I hope
> it s directed to the right place.
>
> I acquired a four-port serial card that I'm trying to identify.
>
> I've checked out the latest serial-howto but to no avail so I'm hoping
> someone on this list may be able to assist.
>
> The card in question was made in Australia about 1992 (copyright allaw
> 1992) and carries the identification COM-4 (a brand name ??).
>
> It has four 16550 UARTS and individual jumpers for each port to set comport
> number and IRQ. Additionally, there is an 8 way DIP switch which permits
> selection of operation under a single IRQ, among other things.
>
> The documentation says that Windows, Pick, Xenix, Unix, Concurrent DOS and
> DOS are supported.
>
> I don't have the drivers :-(
>
> Does anyone know anything about this card? My BBS is crying out for it for
> additional radio ports :-)
>
> TIA
>
> Ray Wells VK2TV
> -
> To unsubscribe from this list: send the line "unsubscribe linux-hams" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] RPC match and conntrack modules v2.1
From: Ian Latter @ 2003-01-12 10:33 UTC (permalink / raw)
To: Harald Welte; +Cc: netfilter-devel
Hi Harald,
I didn't get your gz attachment, but I reassembled your patch from
the mailling list archive.
I have done all bar the cache implementation. You may be right
about its usage (and hence its performance) but I'm not sure -- if
NFS only does one RPC lookup per procedure then the ls data will
be a packet per file in the expectation, not the decision making
process, which will put it out of my hands ... I don't have the gear
to test that particular scenario on hand.
I would like to apply the cache stuff, but it looked a little challenging
for the time I had available. I am also interested in combining the
tcp and udp modules into a single module.
I have done a fair bit of work on its cleanliness since you last
saw it.
The file is on the ftp server -- it applies cleanly to 2.4.20. I think
you'll be much happier with that implementation (v2.2).
11572 Jan 12 21:08 pom-rpc-030112-01.tgz
afd50da3f913ba860b69c74030b0a056 pom-rpc-030112-01.tgz
Let me know how you find it ...
----- Original Message -----
>From: "Harald Welte" <laforge@gnumonks.org>
>To: "Ian Latter" <Ian.Latter@mq.edu.au>
>Subject: Re: [PATCH] RPC match and conntrack modules v2.1
>Date: Sat, 11 Jan 2003 01:05:55 +0100
>
> On Sat, Jan 11, 2003 at 09:47:01AM +1100, Ian Latter wrote:
>
> > Cool, thanks .. :-) I think there will be a lot of embedded firewall
> > manufacturers that will enjoy this one ...
>
> agreed :)
>
> > That's correct - there was no NAT built into record-rpc, not even in an
> > old API. I wanted to make the module set complete by writing the
> > corresponding NAT module(s) but I didn't get time. I might be re-inspired
> > later in January if no one else picks it up -- the code should be almost
> > identical to the RSH work module that I wrote, because the connection
> > handling is quite similar ..... actually ... maybe it doesn't need a
> > nat helper; the connections are all initiated from the client to the
> > server, and the internal protocols aren't carrying payloads that need
> > to be rewritten ... so as long as the nat stuff handles "related"
> > streams sanely, then its probably ok ...
>
> no problem, let's just ignore NAT for now.
>
> > > See attached patch. Mostly CodingStyle updates (you seem to like 8 spaces
> > > instead of tab), but also a minor fix:
> > Cool ... could you resent it as a "zip" attachment ... my mail software
> > decodes text attachments which will make all the tabs in your patch
> > spaces again ...
>
> well, here it is as .gz again. Strange mailclient you must be using...
>
> > > btw: I'd really love to see the large chunk of code in the switch
> > > statement of the match() function in ipt_rpc.c be split up in seperate
> > > functions (thus reducing indentation and improving readability).
> > possibly could be ... the gumby way might be to do udp and tcp
> > functions ... but a better way might be to pull out the rpc payload
> > stuff .... I can take a look at that.
>
> thanks.
>
> > > I don't know, but I think esp. in cases where you have lots of rpc
> > > activity (NFS?, I'm not an RPC expert) it might be wise to use a slab
> > > cache for the 'struct request_p' list items.
> > I have not done that before, is there an example some place in the
> > existing modules?
>
> yes, it's done in ip_conntrack_core. see kmem_cache_create /
> kmem_cache_alloc / and related functions. The idea is for the memory
> management to keep a pool of memory chunks of the requested size around,
> in case they are heavily allocated / deallocated. We do this with
> struct sk_buff, struct ip_conntrack.
>
> I'm not sure whether it's worth the effort in the rpc case... But if I'm
> not mistaken in NFSv2, every single file in an 'ls' is a seperate RPC
> request/reply, isn't it?
>
> > > Please integrate my patch [and maybe consider my suggestions, that's of
> > > course up to you], test it and resubmit it.
> > hopefully be done by the end of the weekend/early next week.
>
> no problem, I'll be off over the wekend anyway.
>
> > > Thanks!
> > Thanks for taking a look at it, and providing feed back ...
>
> You're welcome.
> > --
> > Ian Latter
>
> --
> - Harald Welte / laforge@gnumonks.org http://www.gnumonks.org/
>
===========================================================================
=
> "If this were a dictatorship, it'd be a heck of a lot easier, just so long
> as I'm the dictator." -- George W. Bush Dec 18, 2000
>
--
Ian Latter
Internet and Networking Security Officer
Macquarie University
^ permalink raw reply
* Virus Alert
From: antivirus @ 2003-01-12 10:40 UTC (permalink / raw)
To: linux-kernel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 143 bytes --]
Mensaje automático del sistema. Se ha detectado el virus WORM_Sobig.A en fichero Sample.pif . El fichero ha quedado en situacion de( deleted).
^ permalink raw reply
* Re: Sample
From: big @ 2003-01-12 10:40 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 14 bytes --]
Attached file:
[-- Attachment #2: "Sample.pif --]
[-- Type: application/octet-stream, Size: 65536 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.