Re: The never ending hpusbscsi storry
Am Samstag, 5. März 2005 00:28 schrieb Rene Rebe: > Don't ever use hpusbscsi. I though I already told all vedors it is that > broken that they should never ever ship it. It is the first thing that > will be removed in Linux 2.7. > > If it would be me it would be removed from _all kernels right now_ ... It shall be. A patch to do that is in the queue. The other users have gone away. Regards Oliver - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11.1
On Fri, Mar 04, 2005 at 04:28:02PM -0800, Linus Torvalds wrote: > > > On Fri, 4 Mar 2005, Greg KH wrote: > > > On Fri, Mar 04, 2005 at 02:36:14PM -0800, Andrew Morton wrote: > > > But we end up with a cset in the permanent kernel history which simply > > > should not have been there. > > > > Is this really a big deal? > > Once? No. If it ends up being "par for the course", it's bad. The amount of stuff in the sucker tree shouldn't really amount to /that/ many patches should it ? If it does, then 2.6.x is in worse shape than we've all been admitting. Would it be that much work to just send the 'meat' as gnu patches, and leave the not-for-linus stuff alone ? Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: strace on cat /proc/my_file gives results by calling read twice why?
cranium2003 writes the following: > >when i strace cat /proc/my_file i found message >printing twice >Reading a from a /proc file >Reading a from a /proc file > Why that happening? The first read returns some data and returns the number of bytes, and the second one indicates that EOF has been reached by returning 0. A single read call can't do both of those things, so cat needs to do 2 reads. This has nothing to do with /proc or Linux; it is a logical consequence of the way read() is defined, and the job cat is supposed to do: it copies entire files to stdout, so it has to read until EOF. Only if the input file is empty will it see the EOF on the first read. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Logitech MX1000 Horizontal Scrolling
On Fri, Feb 11, 2005 at 08:50:12AM +0100, Jeremy Nickurak wrote: > On ven, 2005-02-04 at 20:54 +0100, Vojtech Pavlik wrote: > > Please try if 2.6.11-rc3 is any better. > > Oddly, my horizontal scroll worked fine as extra buttons under 2.6.10. > 2.6.11-rc3 causes the scroll wheel to appear under X.org 6.8.1 with the > evdev driver as two seperate mouse buttons being pressed simultaneously. The breakage introduced in 2.6.11-rc3 is still observed in 2.6.11. If in fact my configuration is wrong, I'd love to know how and why, as the configuration I'm using worked fine (with the exception of http://bugzilla.kernel.org/show_bug.cgi?id=1786 ) under 2.6.10: > Section "InputDevice" >Identifier "Mouse0" >Driver "mouse" >Option "CorePointer" >Option "Protocol" "evdev" >Option"Dev Phys" "usb-:00:07.2-2.1/input0" >Option "Device" "/dev/input/event-mx1000" >Option "Buttons" "12" >Option"ZAxisMapping" "11 12" >Option "Resolution" "800" > EndSection With an Xmodmap rule: > pointer = 1 2 3 8 9 10 11 12 6 7 4 5 This is to make sure that the scroll wheel shows up as 4/5 as expected, and that the horizontal scroll shows up as 6/7, which most software interprets as the left/right scroll buttons. Xev says that the horizontal scrollers produce: Scroll Left: > ButtonPress event, serial 29, synthetic NO, window 0xe1, > root 0x4a, subw 0x0, time 334935139, (88,104), root:(89,150), > state 0x10, button 6, same_screen YES > ButtonPress event, serial 29, synthetic NO, window 0xe1, > root 0x4a, subw 0x0, time 334935155, (88,104), root:(89,150), > state 0x10, button 5, same_screen YES > ButtonRelease event, serial 29, synthetic NO, window 0xe1, > root 0x4a, subw 0x0, time 334935155, (88,104), root:(89,150), > state 0x1010, button 5, same_screen YES > ButtonRelease event, serial 29, synthetic NO, window 0xe1, > root 0x4a, subw 0x0, time 334935267, (88,104), root:(89,150), > state 0x10, button 6, same_screen YES And right: > ButtonPress event, serial 29, synthetic NO, window 0xe1, > root 0x4a, subw 0x0, time 334935915, (88,104), root:(89,150), > state 0x10, button 7, same_screen YES > ButtonPress event, serial 29, synthetic NO, window 0xe1, > root 0x4a, subw 0x0, time 334935931, (88,104), root:(89,150), > state 0x10, button 4, same_screen YES > ButtonRelease event, serial 29, synthetic NO, window 0xe1, > root 0x4a, subw 0x0, time 334935931, (88,104), root:(89,150), > state 0x810, button 4, same_screen YES > ButtonRelease event, serial 29, synthetic NO, window 0xe1, > root 0x4a, subw 0x0, time 334936027, (88,104), root:(89,150), > state 0x10, button 7, same_screen YES Various software versions below. > [EMAIL PROTECTED]:~$ xdpyinfo | grep 'X.Org version' > X.Org version: 6.8.1.902 > [EMAIL PROTECTED]:~$ uname -a > Linux agaeris 2.6.11-rc3 #1 Thu Feb 10 23:17:14 MST 2005 i686 > GNU/Linux -- Jeremy Nickurak -= Email/Jabber: [EMAIL PROTECTED] =- Remember, when you buy major label CD's, you're paying companies to sue families and independant music. Learn more now at downhillbattle.org. signature.asc Description: Digital signature
Re: Linux 2.6.11.1
On Fri, 4 Mar 2005, Jeff Garzik wrote: > On Fri, Mar 04, 2005 at 01:51:13PM -0800, Andrew Morton wrote: > > Jeff Garzik <[EMAIL PROTECTED]> wrote: ... > > > is this critical? > > > > Doubt it, unless the succeeding patches have a dependency on it. But the > > other patches have not been tested without this one being present. > > > > These patches have been in mm for four weeks, so it's probably OK from a > > stability POV to take them straight into linux-release. If they were > > fresher then the way to handle them would be to merge them into Linus's > > tree and backport in a couple of weeks time. > > Cool, fair enough. linux-release sounds fine. ok, 4 bits not just 2... Be frugal with the patches and don't take just *anything* that looks like a good fix. What you want is a more stable version, meaning less changes as time goes forward. I know it's the first couple days, but it looks like it could easily go the other way... Anyway, I hope this helps. James > > Jeff > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > -- James Bourne | Email:[EMAIL PROTECTED] UNIX Systems Administration | WWW: http://www.hardrock.org Custom UNIX Programming | Linux: The choice of a GNU generation -- "All you need's an occasional kick in the philosophy." Frank Herbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
strace on cat /proc/my_file gives results by calling read twice why?
hello,
I have a /proc file kernel module with its proc
read function as
static char mybuf[1024];
ssize_t my_file_read(struct file *filp, char *buf,
size_t count, loff_t *ppos)
{
printk("Reading a from a /proc file\n");
static int b_read = 0;
int len = strlen(mybuf);
if (len == 0 || b_read) {
b_read = 0;
return 0;
}
if (len > count - 1)
len = count - 1;
copy_to_user(buf, mybuf, len);
put_user(0, [len]);
++len;
b_read = 1;
return len;
}
when i strace cat /proc/my_file i found message
printing twice
Reading a from a /proc file
Reading a from a /proc file
Why that happening?
Also i check by writing to it as cat >
/proc/my_file
and got single result for write function call not
twice as for read.
regards,
cranium
__
Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web
http://birthday.yahoo.com/netrospective/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
which file functions can be used on /proc file?
hello, i found that in struct proc_dir_entry struct file_operations * proc_fops; is defined. and struct file_operations has defined read, write, poll,llseek,ioctl,flush,release,lock etc functions. so can all these functions be used on any /proc entry in usermode as well as in kenrel mode? Also can following functions be used on my own created /proc file kernel module and when to use them as i have alredy struct file_opereations read and write routine that read/write to/from /proc file. typedef int (read_proc_t)(char *page, char **start, off_t off, int count, int *eof, void *data); typedef int (write_proc_t)(struct file *file, const char *buffer, unsigned long count, void *data); typedef int (get_info_t)(char *, char **, off_t, int); regards, cranium. __ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Thu, 3 Mar 2005, Linus Torvalds wrote: > On Thu, 3 Mar 2005, Jeff Garzik wrote: > > > > We have all these problems precisely because _nobody_ is saying "I'm > > only going to accept bug fixes". We _need_ some amount of release > > engineering. Right now we basically have none. > > I agree that this is one of the main problems. > > But look at how to solve it. The _logical_ solution is to have a third > line of defense: we have the -mm trees (wild and wacky patches), and we > have my tree (hopefully not wacky any more), and it would be good to have > a third level tree (which I'm just not interested in, because that one > doesn't do any development any more) which only takes the "so totally not > wild that it's really boring" patches. > > In fact, if somebody maintained that kind of tree, especially in BK, it > would be trivial for me to just pull from it every once in a while (like > ever _day_ if necessary). But for that to work, then that tree would have > to be about so _obviously_ not wild patches that it's a no-brainer. Sorry, I'm just on the end of this thread but I wanted to put in my 2 bits, I was maintaining this type of tree for 2.4 before. It was well received by those who used it and it was stable (h, I'm still running that puppy on a couple well hidden 7.2 servers). The key then was to only put in patches that fixed issues. If it was a hard factual solution to a problem then it went into the patch. BTW, it was just that, a patch (or set of patches) not actually a seperate tree. It was completely focused on stability as that's what I needed for work at the time. > So what's the problem with this approach? It would seem to make everybody > happy: it would reduce my load, it would give people the alternate "2.6.x > base kernel plus fixes only" parallell track, and it would _not_ have the > testability issue (because I think a lot of people would be happy to test > that tree, and if it was always based on the last 2.6.x release, there > would be no issues. It was good for 2.4 and I think for 2.6, the legitimacy (coming from the top down) will be a good thing. It wasn't as widely received in 2.4 due to it not being "officially sanctioned"... BTW, it's not actually that much work. Watching the list and getting feed back on what works and what doesn't is all that it takes. Naturally, there will be a couple "frell, where was I when I did that" patches but that's life in the semi-fast lane. This will be a good thing. Regards James -- James Bourne | Email:[EMAIL PROTECTED] UNIX Systems Administration | WWW: http://www.hardrock.org Custom UNIX Programming | Linux: The choice of a GNU generation -- "All you need's an occasional kick in the philosophy." Frank Herbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] oss/sscape: fix section references
oss/sscape: fix initdata reference used in exit: Error: ./sound/oss/sscape.o .exit.text refers to 007d R_X86_64_PC32 .init.data+0x0003 Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> diffstat:= sound/oss/sscape.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -Naurp ./sound/oss/sscape.c~oss_sscape_sections ./sound/oss/sscape.c --- ./sound/oss/sscape.c~oss_sscape_sections2005-03-01 23:38:12.0 -0800 +++ ./sound/oss/sscape.c2005-03-04 21:32:05.0 -0800 @@ -1393,7 +1393,7 @@ static struct address_info cfg; static struct address_info cfg_mpu; static int __initdata spea = -1; -static int __initdata mss = 0; +static int mss = 0; static int __initdata dma = -1; static int __initdata irq = -1; static int __initdata io = -1; --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFQ] Rules for accepting patches into the linux-releases tree
Shawn Starr wrote: How does this fit into Rusty's trivial patch bot? This process will fold that into a formal method now? Shawn. Nope, no comparison or interaction really. x.y (linux-release) isn't meant for trivial patches at all, whereas trivial isn't meant for critical patches either. List: linux-kernel Subject:[RFQ] Rules for accepting patches into the linux-releases tree From: Greg KH Date: 2005-03-04 22:21:46 Message-ID: <20050304222146.GA1686 () kroah ! com> [Download message RAW] Anything else anyone can think of? Any objections to any of these? I based them off of Linus's original list. thanks, greg k-h -- Rules on what kind of patches are accepted, and what ones are not, into the "linux-release" tree. - It can not bigger than 100 lines, with context. - It must fix only one thing. - It must fix a real bug that bothers people (not a, "This could be a problem..." type thing.) - It must fix a problem that causes a build error (but not for things marked CONFIG_BROKEN), an oops, a hang, or a real security issue. - No "theoretical race condition" issues, unless an explanation of how the race can be exploited. - It can not contain any "trivial" fixes in it (spelling changes, whitespace cleanups, etc.) -- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] oss/nm256: fix section references
oss/nm256_audio: fix init text section reference:
Error: ./sound/oss/nm256_audio.o .text refers to 1847 R_X86_64_PC32
.init.text+0x0018
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
diffstat:=
sound/oss/nm256_audio.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -Naurp ./sound/oss/nm256_audio.c~oss_nm256_sections
./sound/oss/nm256_audio.c
--- ./sound/oss/nm256_audio.c~oss_nm256_sections2005-03-01
23:38:08.0 -0800
+++ ./sound/oss/nm256_audio.c 2005-03-04 21:25:20.0 -0800
@@ -1047,7 +1047,7 @@ nm256_peek_for_sig (struct nm256_info *c
* VERSTR is a human-readable version string.
*/
-static int __init
+static int __devinit
nm256_install(struct pci_dev *pcidev, enum nm256rev rev, char *verstr)
{
struct nm256_info *card;
---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc4-mm1] end-of-proces handling for acct-csa
On Wed, 2 Mar 2005, Guillaume Thouvenin wrote: > Is it possible to merge BSD and CSA? I mean with CSA, there is a part > that does per-process accounting. For exemple in the > linux-2.6.9.acct_mm.patch the two functions update_mem_hiwater() and > csa_update_integrals() update fields in the current (and parent) > process. So maybe you can improve the BSD per-process accounting or > maybe CSA can replace the BSD per-process accounting? Yes, that was also my preferred direction - make CSA able to also write BSD acct format, and replace the existing BSD accounting with CSA. However it seems this will still increase the amount of kernel code quite a bit. Sorry for not going into any details, I have to leave right now and will be offline for two weeks. Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] oss/cs4281: fix initdata section references
oss/cs4281: fix initdata section references:
Error: ./sound/oss/cs4281/cs4281.o .text refers to 6dae
R_X86_64_32S .init.data+0x0004
Error: ./sound/oss/cs4281/cs4281.o .text refers to 6db6
R_X86_64_32S .init.data
Error: ./sound/oss/cs4281/cs4281m.o .text refers to 6dae
R_X86_64_32S .init.data+0x0004
Error: ./sound/oss/cs4281/cs4281m.o .text refers to 6db6
R_X86_64_32S .init.data
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
diffstat:=
sound/oss/cs4281/cs4281m.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -Naurp ./sound/oss/cs4281/cs4281m.c~oss_cs4281_sections
./sound/oss/cs4281/cs4281m.c
--- ./sound/oss/cs4281/cs4281m.c~oss_cs4281_sections2005-03-01
23:38:33.0 -0800
+++ ./sound/oss/cs4281/cs4281m.c2005-03-04 21:35:51.0 -0800
@@ -4096,7 +4096,7 @@ static /*const */ struct file_operations
static struct initvol {
int mixch;
int vol;
-} initvol[] __initdata = {
+} initvol[] __devinitdata = {
{
SOUND_MIXER_WRITE_VOLUME, 0x4040}, {
---
---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] oss/cmpci: fix initdata section references
oss/cmpci: fix initdata section reference:
Error: ./sound/oss/cmpci.o .text refers to 418e R_X86_64_32S
.init.data+0x0004
Error: ./sound/oss/cmpci.o .text refers to 4196 R_X86_64_32S
.init.data
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
diffstat:=
sound/oss/cmpci.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -Naurp ./sound/oss/cmpci.c~oss_cmpci_sections ./sound/oss/cmpci.c
--- ./sound/oss/cmpci.c~oss_cmpci_sections 2005-03-01 23:38:10.0
-0800
+++ ./sound/oss/cmpci.c 2005-03-04 21:09:15.0 -0800
@@ -2925,7 +2925,7 @@ static /*const*/ struct file_operations
static struct initvol {
int mixch;
int vol;
-} initvol[] __initdata = {
+} initvol[] __devinitdata = {
{ SOUND_MIXER_WRITE_CD, 0x4f4f },
{ SOUND_MIXER_WRITE_LINE, 0x4f4f },
{ SOUND_MIXER_WRITE_MIC, 0x4f4f },
---
---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] oss/es1370: fix initdata section references
oss/es1370: fix initdata section reference:
Error: ./sound/oss/es1370.o .text refers to 42bd R_X86_64_32S
.init.data+0x0024
Error: ./sound/oss/es1370.o .text refers to 42c5 R_X86_64_32S
.init.data+0x0020
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
diffstat:=
sound/oss/es1370.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -Naurp ./sound/oss/es1370.c~oss_es1370_sections ./sound/oss/es1370.c
--- ./sound/oss/es1370.c~oss_es1370_sections2005-03-01 23:38:33.0
-0800
+++ ./sound/oss/es1370.c2005-03-04 21:17:17.0 -0800
@@ -2540,7 +2540,7 @@ MODULE_LICENSE("GPL");
static struct initvol {
int mixch;
int vol;
-} initvol[] __initdata = {
+} initvol[] __devinitdata = {
{ SOUND_MIXER_WRITE_VOLUME, 0x4040 },
{ SOUND_MIXER_WRITE_PCM, 0x4040 },
{ SOUND_MIXER_WRITE_SYNTH, 0x4040 },
---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] oss/esssolo1: fix initdata section references
oss/esssolo1: fix initdata section reference:
Error: ./sound/oss/esssolo1.o .text refers to 0bab R_X86_64_32S
.init.data+0x0004
Error: ./sound/oss/esssolo1.o .text refers to 0bb2 R_X86_64_32S
.init.data
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
diffstat:=
sound/oss/esssolo1.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -Naurp ./sound/oss/esssolo1.c~oss_esssolo1_sections ./sound/oss/esssolo1.c
--- ./sound/oss/esssolo1.c~oss_esssolo1_sections2005-03-01
23:37:48.0 -0800
+++ ./sound/oss/esssolo1.c 2005-03-04 21:19:59.0 -0800
@@ -2193,7 +2193,7 @@ static /*const*/ struct file_operations
static struct initvol {
int mixch;
int vol;
-} initvol[] __initdata = {
+} initvol[] __devinitdata = {
{ SOUND_MIXER_WRITE_VOLUME, 0x4040 },
{ SOUND_MIXER_WRITE_PCM, 0x4040 },
{ SOUND_MIXER_WRITE_SYNTH, 0x4040 },
---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] unexport complete_all
On Fri, Mar 04, 2005 at 12:08:33PM -0500, [EMAIL PROTECTED] wrote: > > Did you just blindly grep the userspace tarball? > > There is no kernel code in there. It's all in linux-2.6.*-autofsng-*.patch. Sorry, my bad. I couldn't connect to your FTP server this morning (I don't know why) and I found the wrong file with Google. This makes my patch void. > Mike Waychison cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
[ I posted it before but nobody anwsered... ] Hi, I just installed 2.6.11 and I was hit by the same bug (or feature?) I found in -rcs. Basically my USB will work only if acpi=off was passed to the kernel. It looks like without acpi=off it will assign IRQ 10 and with acpi=off it will assign IRQ9. It worked at least with 2.6.9. I do not know if the USB is completly broken but at least my speedtouch modem will not work (the red led will be on for some time then completly black). My lspci -vvv (2.6.11 with acpi=off): # lspci -vvv :00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-760 [IGD4-1P] System Controller (rev 13) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Latency: 32 Region 0: Memory at f000 (32-bit, prefetchable) Region 1: Memory at f7003000 (32-bit, prefetchable) [size=4K] Region 2: I/O ports at c000 [disabled] [size=4] Capabilities: [a0] AGP version 2.0 Status: RQ=16 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4 Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW+ Rate=x4 :00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-760 [IGD4-1P] AGP Bridge (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Latency: 32 Bus: primary=00, secondary=01, subordinate=01, sec-latency=32 I/O behind bridge: f000-0fff Memory behind bridge: f400-f5ff Prefetchable memory behind bridge: e800-efff BridgeCtl: Parity- SERR+ NoISA+ VGA+ MAbort- >Reset- FastB2B- :00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40) Subsystem: ABIT Computer Corp. KG7-Lite Mainboard Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Latency: 0 Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) Subsystem: VIA Technologies, Inc. VT82C586/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Latency: 32 Region 4: I/O ports at c400 [size=16] Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 1a) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Latency: 32, cache line size 08 Interrupt: pin D routed to IRQ 9 Region 4: I/O ports at c800 [size=32] Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :00:07.3 USB Controller: VIA Technologies, Inc. USB (rev 1a) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Latency: 32, cache line size 08 Interrupt: pin D routed to IRQ 9 Region 4: I/O ports at cc00 [size=32] Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :00:07.4 SMBus: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40) Subsystem: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Interrupt: pin ? routed to IRQ 11 Capabilities: [68] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :00:09.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF-
Re: radeonfb blanks my monitor
> > Frédéric, can you check in /etc/modprobe.conf if you have a > > line like: options i2c-algo-bit bit_test=1 If you do, please > > comment it out and see if it changes anything. > > Yes, I had, but commenting it out didn't change anything. I can confirm that. Adding bit_test=1 here did NOT cause any problem on my two Radeon systems, so the problem you have isn't related to this option. Sorry for the noise (but I guess it was still worth trying). -- Jean Delvare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] oss/pss: fix section references
oss/pss: fix initdata reference used in exit: Error: ./sound/oss/pss.o .exit.text refers to 003f R_X86_64_PC32 .init.data+0x0003 Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> diffstat:= sound/oss/pss.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -Naurp ./sound/oss/pss.c~oss_pss_sections ./sound/oss/pss.c --- ./sound/oss/pss.c~oss_pss_sections 2005-03-01 23:38:33.0 -0800 +++ ./sound/oss/pss.c 2005-03-04 21:29:26.0 -0800 @@ -1149,7 +1149,7 @@ static int mss_irq __initdata = -1; static int mss_dma __initdata = -1; static int mpu_io __initdata = -1; static int mpu_irq __initdata = -1; -static int pss_no_sound __initdata = 0;/* Just configure non-sound components */ +static int pss_no_sound = 0; /* Just configure non-sound components */ static int pss_keep_settings = 1; /* Keep hardware settings at module exit */ static char *pss_firmware = "/etc/sound/pss_synth"; --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11.1
Sounds great, I can be a QA resource for what machines I have. How do people get involved in QAing these releases? What other help? Shawn. > List: linux-kernel > Subject:Linux 2.6.11.1 > From: Greg KH > Date: 2005-03-04 17:53:02 > Message-ID: <20050304175302.GA29289 () kroah ! com> > [Download message RAW] > > For those of you who haven't waded through the huge "RFD: Kernel release > numbering" thread on lkml to realize that we are now going to start > putting out 2.6.x.y releases, here's the summary: > > A few of us $suckers will be trying to maintain a 2.6.x.y set of > releases that happen after 2.6.x is released. It will contain > only a set of bugfixes and security fixes that meet a strict set > of guidelines, as defined by Linus at: > http://article.gmane.org/gmane.linux.kernel/283396 > > Chris Wright and I are going to start working on doing this work, we > will have a @kernel.org to post these types of bug fixes to, > and a set of people we bounce the patches off of to test for "smells > good" validation. We will also have a bk-commits type mailing list for > those who want to watch the patches flow in, and a bk tree from which > changsets can be pulled from. > > Chris and I will be hashing all of the details out next Tuesday, and > hopefully all the infrastructure will be in place soon. When that > happens, we will post the full details on how all of this is going to > work. In the meantime, feel free to CC: me and Chris on patches that > everyone thinks should go into the 2.6.11.y releases. > > But right now, Chris is on a plane, and we don't have the email alias > set up, or the proper permissions set up on kernel.org to push changes > into the v2.6 directory, but we have a few bugs that are needing to be > fixed in the 2.6.11 release. And since our mantra is, "release early > and often", here's the first release. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][0/3] swsusp: use non-contiguous memory
Hi! > The following set of patches is designed to fix a problem in the current > implementation of swsusp in mainline kernels. Namely, swsusp uses > an array of page backup entries (aka pagedir) to store pointers to memory > pages that must be saved during suspend and restored during resume. > > Unfortunately, the pagedir has to be located in a contiguous chunk of memory > and it sometimes turns out that an 8-order or even 9-order allocation is > needed > for this purpose. It sometimes is impossible to get such an allocation and > swsusp may fail during either suspend or resume due to the lack of memory, > although theoretically there is enough free memory for it to succeed. > > Moreover, swsusp is more likely to fail for this reason during resume, which > means that it may fail during resume after a successful suspend > (this actually has happened for some people, including me :-)) and this, > potentially, may lead to the loss of data. > > The problem is fixed by replacing the pagedir with a linklist so that > high-order memory allocations are avoided (the patches make swsusp use only > 0-order allocations). Unfortunately this means that it's necessary to change > assembly routines used to restore the image after it's been loaded from > swap so that they walk the list instead of walking the array. > > The patches are organized in the following way: > > [1] suspend part > This patch makes swsusp allocate only individual pages during suspend. > It does not require any changes to assembly routines and is > architecture-independent. > It has been present in the -mm kernels for some time. > It contains some additional clean-ups and fixes from Pavel Machek > and Adrian Bunk. > > [2] main resume part (core, i386, x86-64) > This patch makes swsusp allocate only individual pages during resume. > It contains the necessary changes to the assembly routines etc. for i386 > and x86-64. > It depends on the suspend part. > > [3] resume part - ppc support > This patch contains the necessary changes to the assembly routines > etc. for ppc. > It depends on the main resume part. > It's a Hu Gang's patch. > > The patches are against 2.6.11. > > Well, I hope I did it right. ;-) Please consider for applying. Wow, very nice summary. ACK on all 3 patches... Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] i2c-core.c: make some code static
ChangeSet 1.2096, 2005/03/02 12:12:54-08:00, [EMAIL PROTECTED]
[PATCH] i2c-core.c: make some code static
This patch makes some needlessly global code static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/i2c/i2c-core.c | 79 -
include/linux/i2c.h|2 -
2 files changed, 39 insertions(+), 42 deletions(-)
diff -Nru a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
--- a/drivers/i2c/i2c-core.c2005-03-04 12:24:57 -08:00
+++ b/drivers/i2c/i2c-core.c2005-03-04 12:24:57 -08:00
@@ -38,12 +38,43 @@
static DECLARE_MUTEX(core_lists);
static DEFINE_IDR(i2c_adapter_idr);
-int i2c_device_probe(struct device *dev)
+/* match always succeeds, as we want the probe() to tell if we really accept
this match */
+static int i2c_device_match(struct device *dev, struct device_driver *drv)
+{
+ return 1;
+}
+
+static int i2c_bus_suspend(struct device * dev, pm_message_t state)
+{
+ int rc = 0;
+
+ if (dev->driver && dev->driver->suspend)
+ rc = dev->driver->suspend(dev,state,0);
+ return rc;
+}
+
+static int i2c_bus_resume(struct device * dev)
+{
+ int rc = 0;
+
+ if (dev->driver && dev->driver->resume)
+ rc = dev->driver->resume(dev,0);
+ return rc;
+}
+
+static struct bus_type i2c_bus_type = {
+ .name = "i2c",
+ .match =i2c_device_match,
+ .suspend = i2c_bus_suspend,
+ .resume = i2c_bus_resume,
+};
+
+static int i2c_device_probe(struct device *dev)
{
return -ENODEV;
}
-int i2c_device_remove(struct device *dev)
+static int i2c_device_remove(struct device *dev)
{
return 0;
}
@@ -523,38 +554,6 @@
up(>clist_lock);
}
-
-/* match always succeeds, as we want the probe() to tell if we really accept
this match */
-static int i2c_device_match(struct device *dev, struct device_driver *drv)
-{
- return 1;
-}
-
-static int i2c_bus_suspend(struct device * dev, u32 state)
-{
- int rc = 0;
-
- if (dev->driver && dev->driver->suspend)
- rc = dev->driver->suspend(dev,state,0);
- return rc;
-}
-
-static int i2c_bus_resume(struct device * dev)
-{
- int rc = 0;
-
- if (dev->driver && dev->driver->resume)
- rc = dev->driver->resume(dev,0);
- return rc;
-}
-
-struct bus_type i2c_bus_type = {
- .name = "i2c",
- .match =i2c_device_match,
- .suspend = i2c_bus_suspend,
- .resume = i2c_bus_resume,
-};
-
static int __init i2c_init(void)
{
int retval;
@@ -860,7 +859,7 @@
/* CRC over count bytes in the first array plus the bytes in the rest
array if it is non-null. rest[0] is the (length of rest) - 1
and is included. */
-u8 i2c_smbus_partial_pec(u8 crc, int count, u8 *first, u8 *rest)
+static u8 i2c_smbus_partial_pec(u8 crc, int count, u8 *first, u8 *rest)
{
int i;
@@ -872,7 +871,7 @@
return crc;
}
-u8 i2c_smbus_pec(int count, u8 *first, u8 *rest)
+static u8 i2c_smbus_pec(int count, u8 *first, u8 *rest)
{
return i2c_smbus_partial_pec(0, count, first, rest);
}
@@ -880,8 +879,8 @@
/* Returns new "size" (transaction type)
Note that we convert byte to byte_data and byte_data to word_data
rather than invent new xxx_PEC transactions. */
-int i2c_smbus_add_pec(u16 addr, u8 command, int size,
- union i2c_smbus_data *data)
+static int i2c_smbus_add_pec(u16 addr, u8 command, int size,
+union i2c_smbus_data *data)
{
u8 buf[3];
@@ -910,8 +909,8 @@
return size;
}
-int i2c_smbus_check_pec(u16 addr, u8 command, int size, u8 partial,
-union i2c_smbus_data *data)
+static int i2c_smbus_check_pec(u16 addr, u8 command, int size, u8 partial,
+ union i2c_smbus_data *data)
{
u8 buf[3], rpec, cpec;
diff -Nru a/include/linux/i2c.h b/include/linux/i2c.h
--- a/include/linux/i2c.h 2005-03-04 12:24:57 -08:00
+++ b/include/linux/i2c.h 2005-03-04 12:24:57 -08:00
@@ -134,8 +134,6 @@
};
#define to_i2c_driver(d) container_of(d, struct i2c_driver, driver)
-extern struct bus_type i2c_bus_type;
-
#define I2C_NAME_SIZE 50
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Remove pci_dev->slot_name
ChangeSet 1.1998.11.7, 2005/02/07 14:37:01-08:00, [EMAIL PROTECTED] [PATCH] Remove pci_dev->slot_name This is a pointer to dev.bus_id, which is properly accessed through the pci_name() function. Signed-off-by: Dave Jones <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> include/linux/pci.h |2 -- 1 files changed, 2 deletions(-) diff -Nru a/include/linux/pci.h b/include/linux/pci.h --- a/include/linux/pci.h 2005-03-04 12:43:26 -08:00 +++ b/include/linux/pci.h 2005-03-04 12:43:26 -08:00 @@ -549,8 +549,6 @@ unsigned intirq; struct resource resource[DEVICE_COUNT_RESOURCE]; /* I/O and memory regions + expansion ROMs */ - char * slot_name; /* pointer to dev.bus_id */ - /* These fields are used by common fixups */ unsigned inttransparent:1; /* Transparent PCI bridge */ unsigned intmultifunction:1;/* Part of multi-function device */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] new driver for ITM Touch touchscreen
On Fri, Mar 04, 2005 at 07:51:47PM +0100, Hans-Christian Egtvedt wrote: > OK, I'll try to find some better documentation about input devices, any > tips/pointers would be nice. I'm completly new to kernel drivers, I'm used to > writing drivers in embedded systems. > > The driver is made in the way it is today because there is also a driver for > X which read raw events from /dev/input/eventX. It's called lictouch, I have > the source for it too, but I'm not (yet) part of any developing there. Please take a look at 'evtouch' by Kenan Esau, which may fit your bill as an X driver, too. [http://www.conan.de/lifebook] > It would be a really nice feature if one could use the touchscreen as a > legacy interface, but then I would need to be able to calibrate the screen in > the driver and not frontend. At least preferable. It's possible to do that to a certain degree using the EVIOCSABS ioctl(). Only trivial linear calibration is supported, though. -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] I/O-check interface for driver's error handling
On Fri, 2005-03-04 at 23:57 +0100, Pavel Machek wrote: > What prevents driver from being run on another CPU, maybe just doing > mdelay() between hardware accesses? Almost all drivers that I know have some sort of locking. Nothing nasty about it. Besides, you can't expect everything to be as simple as putting two bit of lego together, the problem isn't simple. If an IOs gets there out of sync, it's a non-issue, it will most probably just return all 1's, and if using Seto proposed functions, the bit of code doing it will "know" there was an error and will stop. But a driver notified of errors that, typically, triggered a slot isolation like on pSeries, will have to wait for all IOs to complete anyway, stop everything, so that the slot can be reset. I think you are raising a non-issue. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Potentially dead bttv cards from 2.6.10
As a final update, I added the third card to another machine and that doesn't work either. So after trying 3 kernels on two machines with either one or two cards, and trying the ~120 different card options for bttv to no avail, I'll just guess this card isn't actually supported right now. The strange thing is that it ever worked in the first place, and amazingly that it worked the first time I tried it with no extra effort, yet never again after a reboot, nor on any other machines. I'll take this discussion to the video for linux mailing list and try to find out how to add support for this card. Once it works, I'll see if my test program can still lock up the machine from userspace; If so that'll be a separate issue to debug. Thanks for the help. Jim Bruce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFQ] Rules for accepting patches into the linux-releases tree
How does this fit into Rusty's trivial patch bot? This process will fold that into a formal method now? Shawn. > List: linux-kernel > Subject:[RFQ] Rules for accepting patches into the linux-releases tree > From: Greg KH > Date: 2005-03-04 22:21:46 > Message-ID: <20050304222146.GA1686 () kroah ! com> > [Download message RAW] > > Anything else anyone can think of? Any objections to any of these? > I based them off of Linus's original list. > > thanks, > > greg k-h > > -- > > Rules on what kind of patches are accepted, and what ones are not, into > the "linux-release" tree. > > - It can not bigger than 100 lines, with context. > - It must fix only one thing. > - It must fix a real bug that bothers people (not a, "This could be a >problem..." type thing.) > - It must fix a problem that causes a build error (but not for things >marked CONFIG_BROKEN), an oops, a hang, or a real security issue. > - No "theoretical race condition" issues, unless an explanation of how >the race can be exploited. > - It can not contain any "trivial" fixes in it (spelling changes, >whitespace cleanups, etc.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] I2C: minor I2C cleanups
ChangeSet 1.2110, 2005/03/02 15:03:00-08:00, [EMAIL PROTECTED] [PATCH] I2C: minor I2C cleanups This is one in a series of patches for adding a non-blocking interface to the I2C driver for supporting the IPMI SMBus driver. This patch is a simply some minor cleanups and is in addition to the patch by Mickey Stein (http://marc.theaimsgroup.com/?l=linux-kernel=110919738708916=2). Clean up some general I2C things. Fix some grammar and put () around all the #defines that are compound to avoid nasty side-effects. Signed-off-by: Corey Minyard <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> include/linux/i2c.h | 50 +- 1 files changed, 25 insertions(+), 25 deletions(-) diff -Nru a/include/linux/i2c.h b/include/linux/i2c.h --- a/include/linux/i2c.h 2005-03-04 12:23:20 -08:00 +++ b/include/linux/i2c.h 2005-03-04 12:23:20 -08:00 @@ -187,7 +187,7 @@ char name[32]; /* textual description */ unsigned int id; - /* If an adapter algorithm can't to I2C-level access, set master_xfer + /* If an adapter algorithm can't do I2C-level access, set master_xfer to NULL. If an adapter algorithm can do SMBus access, set smbus_xfer. If set to NULL, the SMBus protocol is simulated using common I2C messages */ @@ -420,22 +420,22 @@ #define I2C_FUNC_SMBUS_READ_BLOCK_DATA_PEC 0x4000 /* SMBus 2.0 */ #define I2C_FUNC_SMBUS_WRITE_BLOCK_DATA_PEC 0x8000 /* SMBus 2.0 */ -#define I2C_FUNC_SMBUS_BYTE I2C_FUNC_SMBUS_READ_BYTE | \ -I2C_FUNC_SMBUS_WRITE_BYTE -#define I2C_FUNC_SMBUS_BYTE_DATA I2C_FUNC_SMBUS_READ_BYTE_DATA | \ - I2C_FUNC_SMBUS_WRITE_BYTE_DATA -#define I2C_FUNC_SMBUS_WORD_DATA I2C_FUNC_SMBUS_READ_WORD_DATA | \ - I2C_FUNC_SMBUS_WRITE_WORD_DATA -#define I2C_FUNC_SMBUS_BLOCK_DATA I2C_FUNC_SMBUS_READ_BLOCK_DATA | \ - I2C_FUNC_SMBUS_WRITE_BLOCK_DATA -#define I2C_FUNC_SMBUS_I2C_BLOCK I2C_FUNC_SMBUS_READ_I2C_BLOCK | \ - I2C_FUNC_SMBUS_WRITE_I2C_BLOCK -#define I2C_FUNC_SMBUS_I2C_BLOCK_2 I2C_FUNC_SMBUS_READ_I2C_BLOCK_2 | \ - I2C_FUNC_SMBUS_WRITE_I2C_BLOCK_2 -#define I2C_FUNC_SMBUS_BLOCK_DATA_PEC I2C_FUNC_SMBUS_READ_BLOCK_DATA_PEC | \ - I2C_FUNC_SMBUS_WRITE_BLOCK_DATA_PEC -#define I2C_FUNC_SMBUS_WORD_DATA_PEC I2C_FUNC_SMBUS_READ_WORD_DATA_PEC | \ - I2C_FUNC_SMBUS_WRITE_WORD_DATA_PEC +#define I2C_FUNC_SMBUS_BYTE (I2C_FUNC_SMBUS_READ_BYTE | \ + I2C_FUNC_SMBUS_WRITE_BYTE) +#define I2C_FUNC_SMBUS_BYTE_DATA (I2C_FUNC_SMBUS_READ_BYTE_DATA | \ + I2C_FUNC_SMBUS_WRITE_BYTE_DATA) +#define I2C_FUNC_SMBUS_WORD_DATA (I2C_FUNC_SMBUS_READ_WORD_DATA | \ + I2C_FUNC_SMBUS_WRITE_WORD_DATA) +#define I2C_FUNC_SMBUS_BLOCK_DATA (I2C_FUNC_SMBUS_READ_BLOCK_DATA | \ + I2C_FUNC_SMBUS_WRITE_BLOCK_DATA) +#define I2C_FUNC_SMBUS_I2C_BLOCK (I2C_FUNC_SMBUS_READ_I2C_BLOCK | \ + I2C_FUNC_SMBUS_WRITE_I2C_BLOCK) +#define I2C_FUNC_SMBUS_I2C_BLOCK_2 (I2C_FUNC_SMBUS_READ_I2C_BLOCK_2 | \ +I2C_FUNC_SMBUS_WRITE_I2C_BLOCK_2) +#define I2C_FUNC_SMBUS_BLOCK_DATA_PEC (I2C_FUNC_SMBUS_READ_BLOCK_DATA_PEC | \ + I2C_FUNC_SMBUS_WRITE_BLOCK_DATA_PEC) +#define I2C_FUNC_SMBUS_WORD_DATA_PEC (I2C_FUNC_SMBUS_READ_WORD_DATA_PEC | \ + I2C_FUNC_SMBUS_WRITE_WORD_DATA_PEC) #define I2C_FUNC_SMBUS_READ_BYTE_PEC I2C_FUNC_SMBUS_READ_BYTE_DATA #define I2C_FUNC_SMBUS_WRITE_BYTE_PEC I2C_FUNC_SMBUS_WRITE_BYTE_DATA @@ -444,14 +444,14 @@ #define I2C_FUNC_SMBUS_BYTE_PECI2C_FUNC_SMBUS_BYTE_DATA #define I2C_FUNC_SMBUS_BYTE_DATA_PEC I2C_FUNC_SMBUS_WORD_DATA -#define I2C_FUNC_SMBUS_EMUL I2C_FUNC_SMBUS_QUICK | \ -I2C_FUNC_SMBUS_BYTE | \ -I2C_FUNC_SMBUS_BYTE_DATA | \ -I2C_FUNC_SMBUS_WORD_DATA | \ -I2C_FUNC_SMBUS_PROC_CALL | \ -I2C_FUNC_SMBUS_WRITE_BLOCK_DATA | \ -I2C_FUNC_SMBUS_WRITE_BLOCK_DATA_PEC | \ -I2C_FUNC_SMBUS_I2C_BLOCK +#define I2C_FUNC_SMBUS_EMUL (I2C_FUNC_SMBUS_QUICK | \ + I2C_FUNC_SMBUS_BYTE | \ + I2C_FUNC_SMBUS_BYTE_DATA | \ + I2C_FUNC_SMBUS_WORD_DATA | \ + I2C_FUNC_SMBUS_PROC_CALL | \ + I2C_FUNC_SMBUS_WRITE_BLOCK_DATA | \ + I2C_FUNC_SMBUS_WRITE_BLOCK_DATA_PEC | \ +
Re: [RFQ] Rules for accepting patches into the linux-releases tree
On Fri, 2005-03-04 at 23:08 -0600, Ian Pilcher wrote: > Greg KH wrote: > > Anything else anyone can think of? Any objections to any of these? > > I based them off of Linus's original list. > > Must already be in Linus tree (i.e. 2.6.X+1)? No, it's cleaner in bitkeeper terms for the patches to be pulled into the linux-releases tree first, and then Linus pulls from that. Linus has said that that is what he intends to do. Shaggy -- David Kleikamp IBM Linux Technology Center - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] initialize a spin lock in CPM2 uart driver
Static initialization of spin locks that are otherwise accessed prior to initialization. Signed-off-by: Jaka Mocnik <[EMAIL PROTECTED]> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> --- diff -Nru a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c --- a/drivers/serial/cpm_uart/cpm_uart_core.c 2005-03-04 23:03:27 -06:00 +++ b/drivers/serial/cpm_uart/cpm_uart_core.c 2005-03-04 23:03:27 -06:00 @@ -864,6 +864,7 @@ .irq= SMC1_IRQ, .ops= _uart_pops, .iotype = SERIAL_IO_MEM, + .lock = SPIN_LOCK_UNLOCKED, }, .flags = FLAG_SMC, .tx_nrfifos = TX_NUM_FIFO, @@ -877,6 +878,7 @@ .irq= SMC2_IRQ, .ops= _uart_pops, .iotype = SERIAL_IO_MEM, + .lock = SPIN_LOCK_UNLOCKED, }, .flags = FLAG_SMC, .tx_nrfifos = TX_NUM_FIFO, @@ -893,6 +895,7 @@ .irq= SCC1_IRQ, .ops= _uart_pops, .iotype = SERIAL_IO_MEM, + .lock = SPIN_LOCK_UNLOCKED, }, .tx_nrfifos = TX_NUM_FIFO, .tx_fifosize = TX_BUF_SIZE, @@ -905,6 +908,7 @@ .irq= SCC2_IRQ, .ops= _uart_pops, .iotype = SERIAL_IO_MEM, + .lock = SPIN_LOCK_UNLOCKED, }, .tx_nrfifos = TX_NUM_FIFO, .tx_fifosize = TX_BUF_SIZE, @@ -917,6 +921,7 @@ .irq= SCC3_IRQ, .ops= _uart_pops, .iotype = SERIAL_IO_MEM, + .lock = SPIN_LOCK_UNLOCKED, }, .tx_nrfifos = TX_NUM_FIFO, .tx_fifosize = TX_BUF_SIZE, @@ -929,6 +934,7 @@ .irq= SCC4_IRQ, .ops= _uart_pops, .iotype = SERIAL_IO_MEM, + .lock = SPIN_LOCK_UNLOCKED, }, .tx_nrfifos = TX_NUM_FIFO, .tx_fifosize = TX_BUF_SIZE, - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] I2C: Trivial indentation fix in i2c/chips/Kconfig
ChangeSet 1.2116, 2005/03/02 16:13:45-08:00, [EMAIL PROTECTED] [PATCH] I2C: Trivial indentation fix in i2c/chips/Kconfig Hi Greg, Quoting myself: > (...) I also think I see an indentation issue on the "tristate" line, > seemingly copied from the SENSORS_DS1621 section which would need to > be fixed as well. Here is the trivial patch fixing that, if you want to apply it. Signed-off-by: Jean Delvare <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> drivers/i2c/chips/Kconfig |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -Nru a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig --- a/drivers/i2c/chips/Kconfig 2005-03-04 12:22:39 -08:00 +++ b/drivers/i2c/chips/Kconfig 2005-03-04 12:22:39 -08:00 @@ -63,7 +63,7 @@ will be called asb100. config SENSORS_DS1621 - tristate "Dallas Semiconductor DS1621 and DS1625" + tristate "Dallas Semiconductor DS1621 and DS1625" depends on I2C && EXPERIMENTAL select I2C_SENSOR help - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PCI: fix pci_remove_legacy_files() crash
ChangeSet 1.1998.11.11, 2005/02/07 16:20:26-08:00, [EMAIL PROTECTED]
[PATCH] PCI: fix pci_remove_legacy_files() crash
The legacy_io which is the member of pci_bus struct might be
NULL. It should be checked.
This patch checks 'b->legacy_io', NULL or not.
Signed-off-by: MUNEDA Takahiro <[EMAIL PROTECTED]>
Acked-by: Jesse Barnes <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/pci/probe.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff -Nru a/drivers/pci/probe.c b/drivers/pci/probe.c
--- a/drivers/pci/probe.c 2005-03-04 12:42:59 -08:00
+++ b/drivers/pci/probe.c 2005-03-04 12:42:59 -08:00
@@ -64,9 +64,11 @@
void pci_remove_legacy_files(struct pci_bus *b)
{
- class_device_remove_bin_file(>class_dev, b->legacy_io);
- class_device_remove_bin_file(>class_dev, b->legacy_mem);
- kfree(b->legacy_io); /* both are allocated here */
+ if (b->legacy_io) {
+ class_device_remove_bin_file(>class_dev, b->legacy_io);
+ class_device_remove_bin_file(>class_dev, b->legacy_mem);
+ kfree(b->legacy_io); /* both are allocated here */
+ }
}
#else /* !HAVE_PCI_LEGACY */
static inline void pci_create_legacy_files(struct pci_bus *bus) { return; }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] I2C: Kill i2c_client.id (2/5)
ChangeSet 1.2084, 2005/03/02 11:52:15-08:00, [EMAIL PROTECTED]
[PATCH] I2C: Kill i2c_client.id (2/5)
(2/5) Stop using i2c_client.id in media/video drivers.
Affected drivers:
* adv7170
* adv7175
* bt819
* bt856
* bttv
* cx88
* ovcamchip
* saa5246a
* saa5249
* saa7110
* saa7111
* saa7114
* saa7134
* saa7185
* tda7432
* tda9840
* tda9875
* tea6415c
* tea6420
* tuner-3036
* vpx3220
Most drivers here would include the id as part of their i2c client name
(e.g. adv7170[0]). This looks more like an habit than something really
needed, so I replaced the various printf by strlcpy, which should be
slightly faster. As said earlier, clients can be differenciated thanks
to their bus id and address if needed, so I don't think that including
this information in the client name is wise anyway.
Other drivers would either set the id to -1 or to a unique value but
then never use it. These drivers are unaffected by the changes.
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/media/video/adv7170.c |5 +
drivers/media/video/adv7175.c |5 +
drivers/media/video/bt819.c| 11 +++
drivers/media/video/bt856.c|5 +
drivers/media/video/bttv-i2c.c |1 -
drivers/media/video/cx88/cx88-i2c.c|1 -
drivers/media/video/ovcamchip/ovcamchip_core.c |1 -
drivers/media/video/saa5246a.c |1 -
drivers/media/video/saa5249.c |1 -
drivers/media/video/saa7110.c |5 +
drivers/media/video/saa7111.c |5 +
drivers/media/video/saa7114.c |5 +
drivers/media/video/saa7134/saa7134-i2c.c |1 -
drivers/media/video/saa7185.c |5 +
drivers/media/video/tda7432.c |1 -
drivers/media/video/tda9840.c |4
drivers/media/video/tda9875.c |1 -
drivers/media/video/tea6415c.c |4
drivers/media/video/tea6420.c |4
drivers/media/video/tuner-3036.c |1 -
drivers/media/video/vpx3220.c | 19 ---
21 files changed, 18 insertions(+), 68 deletions(-)
diff -Nru a/drivers/media/video/adv7170.c b/drivers/media/video/adv7170.c
--- a/drivers/media/video/adv7170.c 2005-03-04 12:26:18 -08:00
+++ b/drivers/media/video/adv7170.c 2005-03-04 12:26:18 -08:00
@@ -402,7 +402,6 @@
.force = force
};
-static int adv7170_i2c_id = 0;
static struct i2c_driver i2c_driver_adv7170;
static int
@@ -432,7 +431,6 @@
client->adapter = adapter;
client->driver = _driver_adv7170;
client->flags = I2C_CLIENT_ALLOW_USE;
- client->id = adv7170_i2c_id++;
if ((client->addr == I2C_ADV7170 >> 1) ||
(client->addr == (I2C_ADV7170 >> 1) + 1)) {
dname = adv7170_name;
@@ -444,8 +442,7 @@
kfree(client);
return 0;
}
- snprintf(I2C_NAME(client), sizeof(I2C_NAME(client)) - 1,
- "%s[%d]", dname, client->id);
+ strlcpy(I2C_NAME(client), dname, sizeof(I2C_NAME(client)));
encoder = kmalloc(sizeof(struct adv7170), GFP_KERNEL);
if (encoder == NULL) {
diff -Nru a/drivers/media/video/adv7175.c b/drivers/media/video/adv7175.c
--- a/drivers/media/video/adv7175.c 2005-03-04 12:26:18 -08:00
+++ b/drivers/media/video/adv7175.c 2005-03-04 12:26:18 -08:00
@@ -452,7 +452,6 @@
.force = force
};
-static int adv7175_i2c_id = 0;
static struct i2c_driver i2c_driver_adv7175;
static int
@@ -482,7 +481,6 @@
client->adapter = adapter;
client->driver = _driver_adv7175;
client->flags = I2C_CLIENT_ALLOW_USE;
- client->id = adv7175_i2c_id++;
if ((client->addr == I2C_ADV7175 >> 1) ||
(client->addr == (I2C_ADV7175 >> 1) + 1)) {
dname = adv7175_name;
@@ -494,8 +492,7 @@
kfree(client);
return 0;
}
- snprintf(I2C_NAME(client), sizeof(I2C_NAME(client)) - 1,
- "%s[%d]", dname, client->id);
+ strlcpy(I2C_NAME(client), dname, sizeof(I2C_NAME(client)));
encoder = kmalloc(sizeof(struct adv7175), GFP_KERNEL);
if (encoder == NULL) {
diff -Nru a/drivers/media/video/bt819.c b/drivers/media/video/bt819.c
--- a/drivers/media/video/bt819.c 2005-03-04 12:26:18 -08:00
+++ b/drivers/media/video/bt819.c 2005-03-04 12:26:18 -08:00
@@ -517,7 +517,6 @@
.force = force
};
-static int bt819_i2c_id = 0;
static struct i2c_driver i2c_driver_bt819;
static int
@@ -546,7 +545,6 @@
client->adapter = adapter;
client->driver = _driver_bt819;
client->flags = I2C_CLIENT_ALLOW_USE;
- client->id = bt819_i2c_id++;
[PATCH] initialize a spin lock in gianfar driver
Initialize the mdio_lock spin lock in mii_info struct, which is otherwise accessed prior to initialization. Signed-off-by: Jaka Mocnik <[EMAIL PROTECTED]> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> --- diff -Nru a/drivers/net/gianfar.c b/drivers/net/gianfar.c --- a/drivers/net/gianfar.c 2005-03-04 23:03:27 -06:00 +++ b/drivers/net/gianfar.c 2005-03-04 23:03:27 -06:00 @@ -377,6 +377,8 @@ ADVERTISED_1000baseT_Full); mii_info->autoneg = 1; + spin_lock_init(_info->mdio_lock); + mii_info->mii_id = priv->einfo->phyid; mii_info->dev = dev; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PCI: Dynids - passing driver data
ChangeSet 1.1998.11.15, 2005/02/08 12:23:18-08:00, [EMAIL PROTECTED]
[PATCH] PCI: Dynids - passing driver data
Currently, code exists in the pci layer to allow userspace to specify
driver data when adding a pci dynamic id from sysfs. However, this data
is never used and there exists no way in the existing code to use it.
This patch allows device drivers to indicate that they want driver data
passed to them on dynamic id adds by initializing use_driver_data in their
pci_driver->pci_dynids struct. The documentation has also been updated
to reflect this.
Signed-off-by: Brian King <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
Documentation/pci.txt|8
drivers/pci/pci-driver.c |1 -
2 files changed, 4 insertions(+), 5 deletions(-)
diff -Nru a/Documentation/pci.txt b/Documentation/pci.txt
--- a/Documentation/pci.txt 2005-03-04 12:42:31 -08:00
+++ b/Documentation/pci.txt 2005-03-04 12:42:31 -08:00
@@ -99,10 +99,10 @@
Users need pass only as many fields as necessary; vendor, device,
subvendor, and subdevice fields default to PCI_ANY_ID (),
class and classmask fields default to 0, and driver_data defaults to
-0UL. Device drivers must call
- pci_dynids_set_use_driver_data(pci_driver *, 1)
-in order for the driver_data field to get passed to the driver.
-Otherwise, only a 0 is passed in that field.
+0UL. Device drivers must initialize use_driver_data in the dynids struct
+in their pci_driver struct prior to calling pci_register_driver in order
+for the driver_data field to get passed to the driver. Otherwise, only a
+0 is passed in that field.
When the driver exits, it just calls pci_unregister_driver() and the PCI layer
automatically calls the remove hook for all devices handled by the driver.
diff -Nru a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
--- a/drivers/pci/pci-driver.c 2005-03-04 12:42:31 -08:00
+++ b/drivers/pci/pci-driver.c 2005-03-04 12:42:31 -08:00
@@ -115,7 +115,6 @@
static inline void
pci_init_dynids(struct pci_dynids *dynids)
{
- memset(dynids, 0, sizeof(*dynids));
spin_lock_init(>lock);
INIT_LIST_HEAD(>list);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] w1: get rid of the potential problems with atomic operations.
ChangeSet 1.2085, 2005/03/02 16:59:41-08:00, [EMAIL PROTECTED]
[PATCH] w1: get rid of the potential problems with atomic operations.
Get rid of the potential problems with atomic operations.
According to upcoming atomic_ops.txt by David Miller and Anton Blanchard
some archs may reoder atomic operations with nonatomic, since
the former are always visible but the latter are not, this can lead
to unpredicted behaviour.
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/w1/w1_family.c |2 ++
drivers/w1/w1_therm.c |2 ++
2 files changed, 4 insertions(+)
diff -Nru a/drivers/w1/w1_family.c b/drivers/w1/w1_family.c
--- a/drivers/w1/w1_family.c2005-03-04 12:37:51 -08:00
+++ b/drivers/w1/w1_family.c2005-03-04 12:37:51 -08:00
@@ -138,7 +138,9 @@
void __w1_family_get(struct w1_family *f)
{
+ smp_mb__before_atomic_inc();
atomic_inc(>refcnt);
+ smp_mb__after_atomic_inc();
}
EXPORT_SYMBOL(w1_family_get);
diff -Nru a/drivers/w1/w1_therm.c b/drivers/w1/w1_therm.c
--- a/drivers/w1/w1_therm.c 2005-03-04 12:37:51 -08:00
+++ b/drivers/w1/w1_therm.c 2005-03-04 12:37:51 -08:00
@@ -104,6 +104,7 @@
int i, max_trying = 10;
atomic_inc(>refcnt);
+ smp_mb__after_atomic_inc();
if (down_interruptible(>master->mutex)) {
count = 0;
goto out_dec;
@@ -179,6 +180,7 @@
out:
up(>mutex);
out_dec:
+ smp_mb__before_atomic_inc();
atomic_dec(>refcnt);
return count;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] I2C: saa7146 build fix
ChangeSet 1.2112, 2005/03/02 15:03:32-08:00, [EMAIL PROTECTED] [PATCH] I2C: saa7146 build fix include/media/saa7146.h:160: parse error before `*' include/media/saa7146.h:160: warning: function declaration isn't a prototype Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> include/media/saa7146.h |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -Nru a/include/media/saa7146.h b/include/media/saa7146.h --- a/include/media/saa7146.h 2005-03-04 12:23:06 -08:00 +++ b/include/media/saa7146.h 2005-03-04 12:23:06 -08:00 @@ -157,7 +157,7 @@ /* from saa7146_i2c.c */ int saa7146_i2c_adapter_prepare(struct saa7146_dev *dev, struct i2c_adapter *i2c_adapter, u32 bitrate); -int saa7146_i2c_transfer(struct saa7146_dev *saa, const struct *i2c_msg msgs, int num, int retries); +int saa7146_i2c_transfer(struct saa7146_dev *saa, const struct i2c_msg *msgs, int num, int retries); /* from saa7146_core.c */ extern struct list_head saa7146_devices; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] I2C: improve debugging output
ChangeSet 1.2102, 2005/03/02 12:18:03-08:00, [EMAIL PROTECTED]
[PATCH] I2C: improve debugging output
Rework the pca_xfer() function to always print the number of
successfully completed transfers in a series when debugging, even when
exiting with an error.
Signed-off-by: Ian Campbell <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/i2c/algos/i2c-algo-pca.c | 28
1 files changed, 16 insertions(+), 12 deletions(-)
diff -Nru a/drivers/i2c/algos/i2c-algo-pca.c b/drivers/i2c/algos/i2c-algo-pca.c
--- a/drivers/i2c/algos/i2c-algo-pca.c 2005-03-04 12:24:16 -08:00
+++ b/drivers/i2c/algos/i2c-algo-pca.c 2005-03-04 12:24:16 -08:00
@@ -186,6 +186,7 @@
int curmsg;
int numbytes = 0;
int state;
+ int ret;
state = pca_status(adap);
if ( state != 0xF8 ) {
@@ -218,6 +219,7 @@
}
curmsg = 0;
+ ret = -EREMOTEIO;
while (curmsg < num) {
state = pca_status(adap);
@@ -251,7 +253,7 @@
case 0x20: /* SLA+W has been transmitted; NOT ACK has been
received */
DEB2("NOT ACK received after SLA+W\n");
pca_stop(adap);
- return -EREMOTEIO;
+ goto out;
case 0x40: /* SLA+R has been transmitted; ACK has been received
*/
pca_rx_ack(adap, msg->len > 1);
@@ -263,7 +265,7 @@
numbytes++;
pca_rx_ack(adap, numbytes < msg->len - 1);
break;
- }
+ }
curmsg++; numbytes = 0;
if (curmsg == num)
pca_stop(adap);
@@ -274,15 +276,15 @@
case 0x48: /* SLA+R has been transmitted; NOT ACK has been
received */
DEB2("NOT ACK received after SLA+R\n");
pca_stop(adap);
- return -EREMOTEIO;
+ goto out;
case 0x30: /* Data byte in I2CDAT has been transmitted; NOT ACK
has been received */
DEB2("NOT ACK received after data byte\n");
- return -EREMOTEIO;
+ goto out;
case 0x38: /* Arbitration lost during SLA+W, SLA+R or data
bytes */
DEB2("Arbitration lost\n");
- return -EREMOTEIO;
+ goto out;
case 0x58: /* Data byte has been received; NOT ACK has been
returned */
if ( numbytes == msg->len - 1 ) {
@@ -297,21 +299,21 @@
"Not final byte. numbytes %d. len %d\n",
numbytes, msg->len);
pca_stop(adap);
- return -EREMOTEIO;
+ goto out;
}
break;
case 0x70: /* Bus error - SDA stuck low */
DEB2("BUS ERROR - SDA Stuck low\n");
pca_reset(adap);
- return -EREMOTEIO;
+ goto out;
case 0x90: /* Bus error - SCL stuck low */
DEB2("BUS ERROR - SCL Stuck low\n");
pca_reset(adap);
- return -EREMOTEIO;
+ goto out;
case 0x00: /* Bus error during master or slave mode due to
illegal START or STOP condition */
DEB2("BUS ERROR - Illegal START or STOP\n");
pca_reset(adap);
- return -EREMOTEIO;
+ goto out;
default:
printk(KERN_ERR DRIVER ": unhandled SIO state
0x%02x\n", state);
break;
@@ -319,11 +321,13 @@
}
- DEB1(KERN_CRIT "}}} transfered %d messages. "
+ ret = curmsg;
+ out:
+ DEB1(KERN_CRIT "}}} transfered %d/%d messages. "
"status is %#04x. control is %#04x\n",
-num, pca_status(adap),
+curmsg, num, pca_status(adap),
pca_get_con(adap));
- return curmsg;
+ return ret;
}
static u32 pca_func(struct i2c_adapter *adap)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] w1: dscore cleanups. 2/2
ChangeSet 1.2081, 2005/03/02 16:58:36-08:00, [EMAIL PROTECTED]
[PATCH] w1: dscore cleanups. 2/2
Trivial cleanups, mostly static/non static, removed unneded exports.
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/w1/dscore.c | 24 ++--
1 files changed, 14 insertions(+), 10 deletions(-)
diff -Nru a/drivers/w1/dscore.c b/drivers/w1/dscore.c
--- a/drivers/w1/dscore.c 2005-03-04 12:38:18 -08:00
+++ b/drivers/w1/dscore.c 2005-03-04 12:38:18 -08:00
@@ -148,7 +148,7 @@
return count;
}
-int ds_recv_status(struct ds_device *dev, struct ds_status *st)
+static int ds_recv_status(struct ds_device *dev, struct ds_status *st)
{
unsigned char buf[64];
int count, err = 0, i;
@@ -206,7 +206,7 @@
return err;
}
-int ds_recv_data(struct ds_device *dev, unsigned char *buf, int size)
+static int ds_recv_data(struct ds_device *dev, unsigned char *buf, int size)
{
int count, err;
struct ds_status st;
@@ -234,7 +234,7 @@
return count;
}
-int ds_send_data(struct ds_device *dev, unsigned char *buf, int len)
+static int ds_send_data(struct ds_device *dev, unsigned char *buf, int len)
{
int count, err;
@@ -774,15 +774,19 @@
EXPORT_SYMBOL(ds_write_byte);
EXPORT_SYMBOL(ds_write_bit);
EXPORT_SYMBOL(ds_write_block);
+EXPORT_SYMBOL(ds_reset);
+EXPORT_SYMBOL(ds_get_device);
+EXPORT_SYMBOL(ds_put_device);
+
+/*
+ * This functions can be used for EEPROM programming,
+ * when driver will be included into mainline this will
+ * require uncommenting.
+ */
+#if 0
EXPORT_SYMBOL(ds_start_pulse);
EXPORT_SYMBOL(ds_set_speed);
-EXPORT_SYMBOL(ds_reset);
EXPORT_SYMBOL(ds_detect);
EXPORT_SYMBOL(ds_stop_pulse);
-EXPORT_SYMBOL(ds_send_data);
-EXPORT_SYMBOL(ds_recv_data);
-EXPORT_SYMBOL(ds_recv_status);
EXPORT_SYMBOL(ds_search);
-EXPORT_SYMBOL(ds_get_device);
-EXPORT_SYMBOL(ds_put_device);
-
+#endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ patch 5/7] drivers/serial/jsm: new serial device driver
Jeff Garzik wrote:
Wen Xiong wrote:
+/* Our "in use" variables, to enforce 1 open only */
+static int jsm_mgmt_in_use[MAXMGMTDEVICES];
Eliminate MAXMGMTDEVICES
+
+/*
+ * jsm_mgmt_open() + *
+ * Open the mgmt/downld/dpa device
+ */ +int jsm_mgmt_open(struct inode *inode, struct file *file)
+{
+unsigned long lock_flags;
+unsigned int minor = JSM_MINOR(inode);
+
+DPR_MGMT(("jsm_mgmt_open start.\n"));
+
+spin_lock_irqsave(_global_lock, lock_flags);
+
+/* mgmt device */
+if (minor < MAXMGMTDEVICES) {
+/* Only allow 1 open at a time on mgmt device */
+if (jsm_mgmt_in_use[minor]) {
+spin_unlock_irqrestore(_global_lock, lock_flags);
+return -EBUSY;
+}
+jsm_mgmt_in_use[minor]++;
An interruptible sleep (semaphore?) is usually preferred to EBUSY.
+else {
+spin_unlock_irqrestore(_global_lock, lock_flags);
+return -ENXIO;
+}
+
+spin_unlock_irqrestore(_global_lock, lock_flags);
+
+DPR_MGMT(("jsm_mgmt_open finish.\n"));
+
+return 0;
+}
+
+/*
+ * jsm_mgmt_close()
+ *
+ * Open the mgmt/dpa device
+ */ +int jsm_mgmt_close(struct inode *inode, struct file *file)
+{
+unsigned long lock_flags;
+unsigned int minor = JSM_MINOR(inode);
+
+DPR_MGMT(("jsm_mgmt_close start.\n"));
+
+spin_lock_irqsave(_global_lock, lock_flags);
+
+/* mgmt device */
+if (minor < MAXMGMTDEVICES) {
+if (jsm_mgmt_in_use[minor])
+jsm_mgmt_in_use[minor] = 0;
+}
+spin_unlock_irqrestore(_global_lock, lock_flags);
+
+DPR_MGMT(("jsm_mgmt_close finish.\n"));
+
+return 0;
+}
+
+/*
+ * jsm_mgmt_ioctl()
+ *
+ * ioctl the mgmt/dpa device
+ */ +
+int jsm_mgmt_ioctl(struct inode *inode, struct file *file, unsigned
int cmd, unsigned long arg)
+{
+unsigned long lock_flags;
+void __user *uarg = (void __user *) arg;
+
+DPR_MGMT(("jsm_mgmt_ioctl start.\n"));
+
+switch (cmd) {
+
+case DIGI_GETDD:
+{
+/*
+ * This returns the total number of boards
+ * in the system, as well as driver version
+ * and has space for a reserved entry
+ */
+struct digi_dinfo ddi;
stack usage
+spin_lock_irqsave(_global_lock, lock_flags);
+
+ddi.dinfo_nboards = jsm_NumBoards;
+sprintf(ddi.dinfo_version, "%s", "40002438_A-INKERNEL");
+
+spin_unlock_irqrestore(_global_lock, lock_flags);
+
+DPR_MGMT(("DIGI_GETDD returning numboards: %d version: %s\n",
+ddi.dinfo_nboards, ddi.dinfo_version));
+
+if (copy_to_user(uarg, , sizeof (ddi)))
+return -EFAULT;
+
+break;
+}
+
+case DIGI_GETBD:
+{
+int brd;
+
+struct digi_info di;
ditto
+if (copy_from_user(, uarg, sizeof(int)))
+return -EFAULT;
+
+DPR_MGMT(("DIGI_GETBD asking about board: %d\n", brd));
+
+if ((brd < 0) || (brd > jsm_NumBoards) || (jsm_NumBoards == 0))
+return -ENODEV;
+
+memset(, 0, sizeof(di));
+
+di.info_bdnum = brd;
+
+spin_lock_irqsave(_Board[brd]->bd_lock, lock_flags);
+
+di.info_bdtype = jsm_Board[brd]->dpatype;
+di.info_bdstate = jsm_Board[brd]->dpastatus;
+di.info_ioport = 0;
+di.info_physaddr = (ulong) jsm_Board[brd]->membase;
+di.info_physsize = (ulong) jsm_Board[brd]->membase -
jsm_Board[brd]->membase_end;
+if (jsm_Board[brd]->state != BOARD_FAILED)
+di.info_nports = jsm_Board[brd]->nasync;
+else
+di.info_nports = 0;
+
+spin_unlock_irqrestore(_Board[brd]->bd_lock, lock_flags);
+
+DPR_MGMT(("DIGI_GETBD returning type: %x state: %x ports: %x
size: %x\n",
+di.info_bdtype, di.info_bdstate, di.info_nports,
di.info_physsize));
+
+if (copy_to_user(uarg, , sizeof (di)))
+return -EFAULT;
+
+break;
+}
+
+case DIGI_GET_NI_INFO:
+{
+struct channel_t *ch;
+struct ni_info ni;
+ulong lock_flags;
+uchar mstat = 0;
+uint board = 0;
+uint channel = 0;
+
+if (copy_from_user(, uarg, sizeof(struct ni_info)))
+return -EFAULT;
+
+DPR_MGMT(("DIGI_GETBD asking about board: %d channel: %d\n",
+ni.board, ni.channel));
+
+board = ni.board;
+channel = ni.channel;
+
+/* Verify boundaries on board */
+if ((board < 0) || (board > jsm_NumBoards) || (jsm_NumBoards
== 0))
+return -ENODEV;
+
+/* Verify boundaries on channel */
+if ((channel < 0) || (channel > jsm_Board[board]->nasync))
+return -ENODEV;
+
+ch = jsm_Board[board]->channels[channel];
+
+if (!ch || ch->magic != JSM_CHANNEL_MAGIC)
+return -ENODEV;
+
+memset(, 0, sizeof(ni));
+ni.board = board;
+ni.channel = channel;
+
+spin_lock_irqsave(>ch_lock, lock_flags);
+
+mstat = (ch->ch_mostat | ch->ch_mistat);
Re: [RFQ] Rules for accepting patches into the linux-releases tree
Greg KH wrote: Anything else anyone can think of? Any objections to any of these? I based them off of Linus's original list. Must already be in Linus tree (i.e. 2.6.X+1)? -- Ian Pilcher[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PCI: One more Asus SMBus quirk
ChangeSet 1.1998.11.27, 2005/02/25 15:48:28-08:00, [EMAIL PROTECTED]
[PATCH] PCI: One more Asus SMBus quirk
One more Asus laptop requiring the SMBus quirk (W1N model).
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/pci/quirks.c |1 +
1 files changed, 1 insertion(+)
diff -Nru a/drivers/pci/quirks.c b/drivers/pci/quirks.c
--- a/drivers/pci/quirks.c 2005-03-04 12:41:06 -08:00
+++ b/drivers/pci/quirks.c 2005-03-04 12:41:06 -08:00
@@ -786,6 +786,7 @@
}
if (dev->device == PCI_DEVICE_ID_INTEL_82855PM_HB)
switch (dev->subsystem_device) {
+ case 0x184b: /* W1N notebook */
case 0x186a: /* M6Ne notebook */
asus_hides_smbus = 1;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11.1
On Fri, Mar 04, 2005 at 03:48:20PM -0500, Steven Rostedt wrote: > On Fri, 2005-03-04 at 09:53 -0800, Greg KH wrote: > > > --- > > > > I've released the 2.6.11.1 patch: > > kernel.org/pub/linux/kernel/people/gregkh/v2.6.11/patch-2.6.11.1.gz > > > > With a detailed changelog at: > > kernel.org/pub/linux/kernel/people/gregkh/v2.6.11/ChangeLog-2.6.11.1 > > > > A bitkeeper tree for the 2.6.11.y releases can be found at: > > bk://linux-release.bkbits.net/linux-2.6.11 > > > > The diffstat and short summary of the fixes are below. > > I know this is new, but is this going to be posted on www.kernel.org? See the comments above the part you snipped off, that stated the infrastructure is still being worked on :) So yes, it will get there, hopefully, eventually... thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
On Fri, 4 Mar 2005, Adrian Bunk wrote: > > [...] So ld looks into the lib .a archive, determines that none of > > the symbols in that object file are needed to resolve a reference and > > drops the entire .o file. > Silly question: > What's the advantage of lib-y compared to obj-y? Basically exactly what I quoted above -- unused object files don't get linked into the kernel image and don't take up (wasted) space. On the other hand, files in obj-y get linked into the kernel unconditionally. --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] vfs: adds the S_PRIVATE flag and adds use to security
Jeffrey Mahoney <[EMAIL PROTECTED]> wrote: > > This patch adds an S_PRIVATE flag to inode->i_flags to mark an inode as > filesystem-internal. As such, it should be excepted from the security > infrastructure to allow the filesystem to perform its own access control. OK, thanks. I'll assume that the other three patches are unchanged. I don't think we've heard from the SELinux team regarding these patches? (See http://www.zip.com.au/~akpm/linux/patches/stuff/selinux-reiserfs/) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PCI: allow x86_64 to do pci express
ChangeSet 1.1998.11.19, 2005/02/17 15:06:16-08:00, [EMAIL PROTECTED] [PATCH] PCI: allow x86_64 to do pci express On Mon, Feb 14, 2005 at 10:47:01AM +0100, Piotr Kaczuba wrote: > On Mon, Feb 14, 2005 at 10:18:43AM +0100, Andi Kleen wrote: > > Piotr Kaczuba <[EMAIL PROTECTED]> writes: > > > Is there a reason why "PCI access mode" config option isn't available for > > > x86_64? Due to this, PCIE config options aren't available either. > > > > There is no 64bit PCI BIOS, so access is always direct. > > > > I assume you mean mmconfig access with "PCIE config options", that is > > a separate config option and available. > > I mean the PCIEPORTBUS option which depends on PCI_GOMMCONFIG or > PCI_GOANY. I assume that due to PCI_MMCONFIG / PCI_GOMMCONFIG mismatch > it's not available on x86_64. Ok, that's a bug in PCIEPORTBUS. Best is probably to completely remove the dependency, it doesn't make much sense (the code has to handle the case of mmconfig not being available at runtime anyways) Remove bogus dependency in PCI Express root driver. Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> drivers/pci/pcie/Kconfig |1 - 1 files changed, 1 deletion(-) diff -Nru a/drivers/pci/pcie/Kconfig b/drivers/pci/pcie/Kconfig --- a/drivers/pci/pcie/Kconfig 2005-03-04 12:42:04 -08:00 +++ b/drivers/pci/pcie/Kconfig 2005-03-04 12:42:04 -08:00 @@ -3,7 +3,6 @@ # config PCIEPORTBUS bool "PCI Express support" - depends on PCI_GOMMCONFIG || PCI_GOANY default n ---help--- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Fri, 4 Mar 2005, Rene Herman wrote: Linus Torvalds wrote: I've long since decided that there's no point to making "-pre". What's the difference between a "-pre" and a daily -bk snapshot? Really? The fact that not a script, but Linus Torvalds, decides that the tree is in a state he likes to share with others. You have been doing -pre's all this time, it's just that you are calling them -rc's. remember that there are the nightly CVS dumps and patches being created as well. from my point of view it appears that when Linus releases -rc1 he is hopeing that it's actually going to be final, but since nobody bothers to test before that it has never actually been the case. As a result additional changes need to be done and Linus chooses to fix it by moving forward and doing additional fixes rather then by reverting patches. He does allow some additional patches to move in as well for a little while, but all of them are expected to be fixes. David Lang -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: swsusp: allow resume from initramfs
Hi Pavel et al. On Sat, 2005-03-05 at 04:50, Barry K. Nathan wrote: > On Fri, Mar 04, 2005 at 03:04:10AM -0800, Andrew Morton wrote: > > I don't understand how this can be affected by the modularness of the > > kernel. Can you explain a little more? > > > > Would it not be simpler to just add "resume=03:02" to the boot command line? > > In addition to what others have mentioned, there's also the situation > where swap is on a logical volume. In that case, the initramfs needs to > get LVM up and running before you can even think about resuming. > > Swap on a logical volume is the default Fedora Core 3 partition layout, > and I imagine it's the default for Red Hat Enterprise Linux 4 as well. You guys are reinventing the wheel a lot at the moment and I'm in the middle of doing it for x86_64 lowlevel code :> Can we see if we can work a little more closely - perhaps we can get some shared code going that will allow us to handle these issues without stepping on each others' feet? In particular, shared code for - initramfs and initrd support - lowlevel suspend & resume would be good, wouldn't it? I'm tempted to add setting and checking signatures, but I'm also in the middle of implementing support for writing the image to a file, so that could get messy. Regards, Nigel -- Nigel Cunningham Software Engineer, Canberra, Australia http://www.cyclades.com Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028; Mob: +61 (417) 100 574 Maintainer of Suspend2 Kernel Patches http://suspend2.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: swsusp: allow resume from initramfs
Hi. On Sat, 2005-03-05 at 08:43, Pavel Machek wrote: > > You guys are reinventing the wheel a lot at the moment and I'm in the > > middle of doing it for x86_64 lowlevel code :> Can we see if we can work > > a little more closely - perhaps we can get some shared code going that > > will allow us to handle these issues without stepping on each others' > > feet? In particular, shared code for > > > > - initramfs and initrd support > > Its actually done, and it was few strategically placed lines of code > (like 20 lines). I do not think it can be meaningfully shared. Mmm. But if we're both putting hooks in the same places... > > - lowlevel suspend & resume > > This makes very good sense to share. We have i386, x86-64 and ppc > versions. They simply walk list of pbe's; that should be simple enough > to be usable for suspend2, too The CPU save and restore, yes. But I use a different format for recording the image metadata (I use bitmaps to record the locations of pages). Perhaps I should hasten to mention the bitmaps are discontiguous - single pages connected by a kmalloc'd list. The copyback itself will need to stay distinct. Regards, Nigel -- Nigel Cunningham Software Engineer, Canberra, Australia http://www.cyclades.com Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028; Mob: +61 (417) 100 574 Maintainer of Suspend2 Kernel Patches http://softwaresuspend.berlios.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 4/5] audit mips fix
From: Yoichi Yuasa <[EMAIL PROTECTED]>
CC arch/mips/kernel/ptrace.o
arch/mips/kernel/ptrace.c: In function 'do_syscall_trace':
arch/mips/kernel/ptrace.c:310: warning: implicit declaration of function
'audit_syscall_entry'
arch/mips/kernel/ptrace.c:310: error: 'struct pt_regs' has no member named
'orig_eax'
arch/mips/kernel/ptrace.c:314: warning: implicit declaration of function
'audit_syscall_exit'
Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/arch/mips/kernel/ptrace.c |3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
diff -puN arch/mips/kernel/ptrace.c~audit-mips-fix arch/mips/kernel/ptrace.c
--- 25/arch/mips/kernel/ptrace.c~audit-mips-fix 2005-03-04 13:16:25.0
-0800
+++ 25-akpm/arch/mips/kernel/ptrace.c 2005-03-04 13:16:25.0 -0800
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -307,7 +308,7 @@ asmlinkage void do_syscall_trace(struct
{
if (unlikely(current->audit_context)) {
if (!entryexit)
- audit_syscall_entry(current, regs->orig_eax,
+ audit_syscall_entry(current, regs->regs[2],
regs->regs[4], regs->regs[5],
regs->regs[6], regs->regs[7]);
else
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11.1
On Fri, Mar 04, 2005 at 01:15:37PM -0800, Andrew Morton wrote: > Greg KH <[EMAIL PROTECTED]> wrote: > > > > > Here's the list of things which we might choose to put into 2.6.11.2. I > > > was > > > planning on sending them in for 2.6.12 when that was going to be > > > errata-only. > > > > Ok, care to forward them on? > > Sure. How do they get to Linus? Hm, either he pulls them from our new 2.6.x.y tree, or they go to him through you. Either way, I'd recommend sending them to him for now, until we get this whole "procedure" worked out. > > Hm, odds are the nfsd one doesn't fit our list of "acceptable things", > > Was there such a list? It's kinda what I'm asking about here. There is, I'll post an initial version of it in a bit. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Suggestions for patch
Hi,
I have a suggestion for the openbsd net security patch.
In the function static int tcp_v4_get_port(struct sock *sk, unsigned short snum)
there's the code that says:
rover = tcp_port_rover;
(like 224 on the version of tcp_ipv4.c patched with your patch for rc2 of
2.6.11)
I would like to suggest to change it to:
get_random_bytes(, sizeof(rover));
no checks around it: that's already been taken care of in the original
code.
And for the ipv6 code:
diff -uNr tcp_ipv6.c.org tcp_ipv6.c
--- tcp_ipv6.c.org 2005-03-04 22:28:53.181183066 +0100
+++ tcp_ipv6.c 2005-03-04 22:32:56.425994913 +0100
@@ -138,8 +138,8 @@
int remaining = (high - low) + 1;
int rover;
+ get_random_bytes(, sizeof(rover));
spin_lock(_portalloc_lock);
- rover = tcp_port_rover;
do {rover++;
if ((rover < low) || (rover > high))
rover = low;
Folkert van Heusden
Op zoek naar een IT of Finance baan? Mail me voor de mogelijkheden!
+--+
|UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/)|
|a try, it brings monitoring logfiles to a different level! See|
|http://vanheusden.com/multitail/features.html for a feature list. |
+--= www.unixsoftware.nl =-+
Phone: +31-6-41278122, PGP-key: 1F28D8AE
Get your PGP/GPG key signed at www.biglumber.com!
signature.asc
Description: Digital signature
Re: RFD: Kernel release numbering
On Fri, Mar 04, 2005 at 12:37:05PM -0800, Linus Torvalds wrote: >... > I used to do "-pre", a long time ago. Exactly because they were > synchronization points for developers. >... > So the point of -pre's are gone. Have people actually _looked_ at the -rc > releases? They are very much done when I reach the point and say "ok, > let's calm down". The first one is usually pretty big and often needs some > fixing, simply because the first one is _inevitably_ (and by design) the > one that gets the pent-up demand from the previous calming down period. > > But it's very much a call to "ok, guys, calm down now". My impression about your releases is that -rc1 is a first snapshot, but there are still invasive changes until -rc3 or -rc4 when you _really_ say "only obvious bug fixes will be accepted". It's _only about naming_: Name the first one -pre1 instead of -rc1 and the snapshot you announce with "only obvious bug fixes will be accepted" -rc1. It might not matter for you how it's called, but it does matter for other people and it doesn't cost you any extra effort. > And if you aren't calming down, it's _your_ problem. Complaining about > naming of -pre vs -rc is pointless. >... If I send a non-bugfix patch to Marcelo after 2.4.30-rc1 he'll say: "Thanks, queued for 2.4.31 ." > Linus cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-ck1 (cfq-timeslice)
Vincent Vanackere <[EMAIL PROTECTED]> wrote: > > Speaking of the cfq-timeslice scheduler, is there a version that > applies to recent -mm kernels ? Yes, what happened to that? > (I can't live without reiser4 any more...). Tell us more? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ patch 7/7] drivers/serial/jsm: new serial device driver
Christoph Hellwig wrote: +config SERIAL_JSM +tristate "Digi International NEO PCI Support" +select SERIAL_CORE shouldn't this depend on CONFIG_PCI? diff -Nuar linux-2.6.9.orig/drivers/serial/jsm/Makefile linux-2.6.9.new/drivers/serial/jsm/Makefile --- linux-2.6.9.orig/drivers/serial/jsm/Makefile 1969-12-31 18:00:00.0 -0600 +++ linux-2.6.9.new/drivers/serial/jsm/Makefile 2005-02-27 17:01:43.725941288 -0600 @@ -0,0 +1,36 @@ +## +# Copyright 2003 Digi International (www.digi.com) +# Scott H Kilau +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2, or (at your option) +# any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY, EXPRESS OR IMPLIED; without even the +# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR +# PURPOSE. See the GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. +# +# +# NOTE TO LINUX KERNEL HACKERS: DO NOT REFORMAT THIS CODE! +# +# Send any bug fixes/changes to: Eng.Linux at digi dot com. +# Thank you. +# +# +## + +# +# Makefile for Jasmine adapter +# + +obj-$(CONFIG_SERIAL_JSM) += jsm.o + +jsm-objs :=jsm_driver.o jsm_mgmt.o jsm_neo.o\ + jsm_proc.o jsm_tty.o + I doubt anyone can register a copyright on a trivial three-line makefile. Also please use jsm-y instead of jsm-objs. Hi Christoph, Thanks for your comments here! wendy Signed-off-by: Wen Xiong <[EMAIL PROTECTED]> diff -Nuar linux-2.6.11.org/drivers/serial/Kconfig linux-2.6.11.new/drivers/serial/Kconfig --- linux-2.6.11.org/drivers/serial/Kconfig 2005-03-04 14:58:19.650874384 -0600 +++ linux-2.6.11.new/drivers/serial/Kconfig 2005-03-04 14:53:06.598937400 -0600 @@ -810,4 +810,19 @@ bool "TX39XX/49XX SIO act as standard serial" depends on !SERIAL_8250 && SERIAL_TXX9 +config SERIAL_JSM +tristate "Digi International NEO PCI Support" +select SERIAL_CORE +help + This is a driver for Digi International's Neo series + of cards which provide multiple serial ports. You would need + something like this to connect more than two modems to your Linux + box, for instance in order to become a dial-in server. This driver + supports PCI boards only. + If you have a card like this, say Y here and read the file + . + + To compile this driver as a module, choose M here: the + module will be called jsm. + endmenu diff -Nuar linux-2.6.11.org/drivers/serial/Makefile linux-2.6.11.new/drivers/serial/Makefile --- linux-2.6.11.org/drivers/serial/Makefile2005-03-04 14:58:11.681887760 -0600 +++ linux-2.6.11.new/drivers/serial/Makefile2005-03-04 14:53:16.985954944 -0600 @@ -49,3 +49,4 @@ obj-$(CONFIG_SERIAL_MPSC) += mpsc.o obj-$(CONFIG_ETRAX_SERIAL) += crisv10.o obj-$(CONFIG_SERIAL_TXX9) += serial_txx9.o +obj-$(CONFIG_SERIAL_JSM) += jsm/ diff -Nuar linux-2.6.11.org/drivers/serial/jsm/Makefile linux-2.6.11.new/drivers/serial/jsm/Makefile --- linux-2.6.11.org/drivers/serial/jsm/Makefile1969-12-31 18:00:00.0 -0600 +++ linux-2.6.11.new/drivers/serial/jsm/Makefile2005-03-04 14:56:26.655878032 -0600 @@ -0,0 +1,10 @@ +# ###/ +# +# Makefile for Jasmine adapter +# + +obj-$(CONFIG_SERIAL_JSM) += jsm.o + +jsm-objs :=jsm_driver.o jsm_mgmt.o jsm_neo.o\ + jsm_tty.o jsm_sysfs.o + diff -Nuar linux-2.6.11.org/include/linux/pci_ids.h linux-2.6.11.new/include/linux/pci_ids.h --- linux-2.6.11.org/include/linux/pci_ids.h2005-03-04 14:57:38.115931232 -0600 +++ linux-2.6.11.new/include/linux/pci_ids.h2005-03-04 15:00:11.796998872 -0600 @@ -1418,6 +1418,15 @@ #define PCI_DEVICE_ID_DIGI_DF_M_E 0x0071 #define PCI_DEVICE_ID_DIGI_DF_M_IOM2_A 0x0072 #define PCI_DEVICE_ID_DIGI_DF_M_A 0x0073 +#define PCI_DEVICE_ID_NEO_4 0x00B0 +#define PCI_DEVICE_ID_NEO_8 0x00B1 +#define PCI_DEVICE_ID_NEO_2DB9 0x00C8 +#define PCI_DEVICE_ID_NEO_2DB9PRI 0x00C9 +#define PCI_DEVICE_ID_NEO_2RJ45 0x00CA +#define PCI_DEVICE_ID_NEO_2RJ45PRI 0x00CB +#define PCI_DEVICE_ID_NEO_1_422 0x00CC +#define PCI_DEVICE_ID_NEO_1_422_485 0x00CD +#define PCI_DEVICE_ID_NEO_2_422_485 0x00CE #define PCI_VENDOR_ID_MUTECH 0x1159 #define PCI_DEVICE_ID_MUTECH_MV10000x0001 diff -Nuar linux-2.6.11.org/include/linux/serial_core.h
Re: Linux 2.6.11.1
Andrew Morton wrote: Greg KH <[EMAIL PROTECTED]> wrote: A few of us $suckers will be trying to maintain a 2.6.x.y set of releases that happen after 2.6.x is released. Just to test things out a bit... Here's the list of things which we might choose to put into 2.6.11.2. I was planning on sending them in for 2.6.12 when that was going to be errata-only. From 2.6.11-mm1: cramfs-small-stat2-fix.patch setup_per_zone_lowmem_reserve-oops-fix.patch dv1394-ioctl-retval-fix.patch ppc32-compilation-fixes-for-ebony-luan-and-ocotea.patch nfsd--sgi-921857-find-broken-with-nohide-on-nfsv3.patch nfsd--exportfs-reduce-stack-usage.patch Unless it's crashing for people, stack usage is IMO a wanted-fix not needed-fix. nfsd--svcrpc-add-a-per-flavor-set_client-method.patch is this critical? Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 1/5] cramfs: small stat(2) fix
From: Eric Lammerts <[EMAIL PROTECTED]>
When I stat(2) a device node on a cramfs, the st_blocks field is bogus
(it's derived from the size field which in this case holds the major/minor
numbers). This makes du(1) output completely wrong.
Signed-off-by: Eric Lammerts <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/fs/cramfs/inode.c |1 +
1 files changed, 1 insertion(+)
diff -puN fs/cramfs/inode.c~cramfs-small-stat2-fix fs/cramfs/inode.c
--- 25/fs/cramfs/inode.c~cramfs-small-stat2-fix 2005-03-04 13:15:57.0
-0800
+++ 25-akpm/fs/cramfs/inode.c 2005-03-04 13:15:57.0 -0800
@@ -70,6 +70,7 @@ static struct inode *get_cramfs_inode(st
inode->i_data.a_ops = _aops;
} else {
inode->i_size = 0;
+ inode->i_blocks = 0;
init_special_inode(inode, inode->i_mode,
old_decode_dev(cramfs_inode->size));
}
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
non-fatal oops with EIP at skb_release_data, available for debugging
This is my K7-800, 256MB RAM machine running as
ed2k/bittorrent 24/7 box... metacity died, but the
windows are still alive (and working) so if someone
wants to get more info about it, just ping me...
[EMAIL PROTECTED] ~]# cat /proc/version
Linux version 2.6.11-rc3-bk8 ([EMAIL PROTECTED]) (gcc version 3.4.2
20041017 (Red Hat 3.4.2-6.fc3)) #1 Sat Feb 12 00:01:28 CET 2005
[EMAIL PROTECTED] ~]# lsmod
Module Size Used by
loop 15368 -
nls_iso8859_1 3840 -
parport_pc 29444 -
parport24704 -
8139too24896 -
floppy 57392 -
>From the dmesg ring:
kernel BUG at include/linux/mm.h:343!
invalid operand: [#1]
PREEMPT
Modules linked in: loop nls_iso8859_1 parport_pc parport 8139too floppy
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00210256 (2.6.11-rc3-bk8)
EIP is at skb_release_data+0x92/0xa0
eax: ebx: ecx: cca36f80 edx: c11a97c0
esi: c4205f20 edi: c4205f20 ebp: cd149dcc esp: cd149dc4
ds: 007b es: 007b ss: 0068
Process metacity (pid: 2109, threadinfo=cd148000 task=ce8935d0)
Stack: c4205f20 cd149dd8 c02da6bb c6e9a0c0 cd149df8 c02da737 c5134250
c4205f20 c5134250 c4205f20 c5134250 cd149e4c c02feba6
0040 cc68c454 0001 cc68c444 cd148000 0001
Call Trace:
[] show_stack+0x7a/0x90
[] show_registers+0x14d/0x1c0
[] die+0xe4/0x180
[] do_invalid_op+0xa3/0xb0
[] error_code+0x2b/0x30
[] kfree_skbmem+0xb/0x20
[] __kfree_skb+0x67/0xf0
[] tcp_recvmsg+0x5f6/0x710
[] sock_common_recvmsg+0x46/0x60
[] sock_aio_read+0xee/0x100
[] do_sync_read+0x97/0xf0
[] vfs_read+0x91/0x120
[] sys_read+0x3d/0x70
[] sysenter_past_esp+0x52/0x75
Code: c9 e9 03 e5 e5 ff 8d 76 00 5b 5e c9 c3 89 d0 e8 c5 f2 e5 ff eb
cf 89 f0 e8 0c ff ff ff 5b 8b 86 98 00 00 00 5e c9 e9 de e4 e5 ff <0f>
0b 57 01 ab c5 35 c0 eb a5 8d 74 26 00 55 89 e5 53 89 c3 e8
Thanks,
--alessandro
"There is no distance that I don't see
I do have a will - No limit to my reach"
(Wallflowers, "Empire In My Mind")
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PCI: Add PCI quirk for SMBus on the Toshiba Satellite A40
ChangeSet 1.1998.11.18, 2005/02/17 15:05:53-08:00, [EMAIL PROTECTED]
[PATCH] PCI: Add PCI quirk for SMBus on the Toshiba Satellite A40
The Toshiba Satellite A40 laptop hides its SMBus device, much like a
number of Asus boards reputedly do. This prevents access to the LM90
hardware monitoring chip. This simple patch extends the PCI quirk used
for the Asus and HP systems to this Toshiba laptop.
Signed-off-by: Frans Pop <[EMAIL PROTECTED]>
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/pci/quirks.c |6 ++
1 files changed, 6 insertions(+)
diff -Nru a/drivers/pci/quirks.c b/drivers/pci/quirks.c
--- a/drivers/pci/quirks.c 2005-03-04 12:42:11 -08:00
+++ b/drivers/pci/quirks.c 2005-03-04 12:42:11 -08:00
@@ -801,6 +801,12 @@
case 0x12bc: /* HP D330L */
asus_hides_smbus = 1;
}
+ } else if (unlikely(dev->subsystem_vendor == PCI_VENDOR_ID_TOSHIBA)) {
+ if (dev->device == PCI_DEVICE_ID_INTEL_82855GM_HB)
+ switch(dev->subsystem_device) {
+ case 0x0001: /* Toshiba Satellite A40 */
+ asus_hides_smbus = 1;
+ }
}
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82845_HB,
asus_hides_smbus_hostbridge );
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11.1
Greg KH <[EMAIL PROTECTED]> wrote: > > On Fri, Mar 04, 2005 at 01:15:37PM -0800, Andrew Morton wrote: > > Greg KH <[EMAIL PROTECTED]> wrote: > > > > > > > Here's the list of things which we might choose to put into 2.6.11.2. > > > > I was > > > > planning on sending them in for 2.6.12 when that was going to be > > > > errata-only. > > > > > > Ok, care to forward them on? > > > > Sure. How do they get to Linus? > > Hm, either he pulls them from our new 2.6.x.y tree, or they go to him > through you. Either way, I'd recommend sending them to him for now, We can do that. As long as the patches remain unaltered I assume that BK will recognise that the patch is already there, in a different cset? > until we get this whole "procedure" worked out. Yup. That's why I'm running this little experiment. Applying stimuli and seeing how we respond. Yum, cheese. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: slab corruption in skb allocs
On Fri, Mar 04, 2005 at 10:19:21PM +0100, Richard Fuchs wrote: > _correction_ to my previous mail, this does _not_ happen with the > eepro100 driver. (sorry for the confusion, i got the kernel images mixed > up with all the testing i've been doing.) > > could this affect the e1000 driver as well? Yes. > >Send the output of ethtool, please. Doh. 'ethtool -k' is what's needed, sorry. If it's reproduceable, try turning off rx/tx hardware checksumming: ethtool -k eth0 rx off tx off -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ patch 6/7] drivers/serial/jsm: new serial device driver
Greg KH wrote:
On Sun, Feb 27, 2005 at 06:40:20PM -0500, Wen Xiong wrote:
diff -Nuar linux-2.6.9.orig/drivers/serial/jsm/digi.h linux-2.6.9.new/drivers/serial/jsm/digi.h
Oh, and please diff against at least the latest kernel release, 2.6.9 is
old...
+ * $Id: digi.h,v 1.7 2004/09/23 16:08:30 scottk Exp $
+ *
+ * NOTE: THIS IS A SHARED HEADER. DO NOT CHANGE CODING STYLE!!!
Not true anymore, right?
+/
+ * Structure to get driver status information
+ /
+struct digi_dinfo {
+ unsigned int dinfo_nboards; /* # boards configured */
+ char dinfo_reserved[12]; /* for future expansion */
+ char dinfo_version[16]; /* driver version */
+};
+
+#define DIGI_GETDD ('d'<<8) | 248 /* get driver info */
All structures that are passed accross the ioctl interface, MUST use the
__u8, __u16, __u32, and friend definitions. unsigned int is not
allowed.
And why have all of these ioctls? Shouldn't most of this stuff be
availble in sysfs instead?
+#ifndef __JSM_DRIVER_H
+#define __JSM_DRIVER_H
+
+#include /* To pick up the varions Linux types */
+#include /* To pick up the various tty structs/defines */
+#include
+#include /* For irqreturn_t type */
+#include /* For irqreturn_t type */
That comment is incorrect.
+/*
+ * Driver identification, error and debugging statments
+ *
+ * In theory, you can change all occurances of "digi" in the next
+ * three lines, and the driver printk's will all automagically change.
+ *
+ * APR((fmt, args, ...)); Always prints message
+ * DPR((fmt, args, ...)); Only prints if JSM_TRACER is defined at
+ * compile time and jsm_debug!=0
+ *
+ * TRC_TO_CONSOLE:
+ * Setting this to 1 will turn on some general function tracing
+ * resulting in a bunch of extra debugging printks to the console
+ *
+ */
+
+#define PROCSTR "jsm" /* /proc entries */
+#define DEVSTR "/dev/dg/jsm" /* /dev entries */
+#define DRVSTR "jsm" /* Driver name string
+ * displayed by APR */
+#define APR(args) do {printk(DRVSTR": "); printk args;} while (0)
Ick. You _must_ use a KERN_ level for a printk, this is not allowed.
Please use the dev_printk and helper functions instead. It's not ok to
create new functions like this.
And again, what's with the double (( when you use this macro?
+#if TRC_TO_CONSOLE
+#define PRINTF_TO_CONSOLE(args) { printk(DRVSTR": "); printk args; }
+#else //!defined TRACE_TO_CONSOLE
+#define PRINTF_TO_CONSOLE(args)
+#endif
+
+#define TRC(args) { PRINTF_TO_CONSOLE(args) }
do { } while 0
+/* Our 3 magic numbers for our board, channel and unit structs */
+#define JSM_BOARD_MAGIC 0x5c6df104
+#define JSM_CHANNEL_MAGIC 0x6c6df104
+#define JSM_UNIT_MAGIC 0x7c6df104
Don't use magic numbers, they are not needed at all. Please just remove
them from the structures, and use the provided kernel slab debug
functions to catch errors that you might have been able to catch with
the magic values.
+ * This file is intended to contain all the kernel "differences" between the
+ * various kernels that we support.
No, please use this for your 2.4 code, not for your 2.6 driver version.
+# define JSM_MOD_INC_USE_COUNT(rtn) (rtn = 1)
+# define JSM_MOD_DEC_USE_COUNT
You shouldn't even be using these macros in your 2.4 code, so please
don't use it here.
diff -Nuar linux-2.6.9.orig/drivers/serial/jsm/jsm_mgmt.h linux-2.6.9.new/drivers/serial/jsm/jsm_mgmt.h
--- linux-2.6.9.orig/drivers/serial/jsm/jsm_mgmt.h 1969-12-31 18:00:00.0 -0600
+++ linux-2.6.9.new/drivers/serial/jsm/jsm_mgmt.h 2005-02-27 17:14:44.747952016 -0600
Do you really need all of these different header files? Why not just
put them all in 1?
+/
+ * Per channel/port NEO UART structure *
+
+ * Base Structure Entries Usage Meanings to Host *
+ * *
+ * W = read write R = read only*
+ * U = Unused. *
+ /
+
+struct neo_uart_struct {
+ volatile uchar txrx; /* WR RHR/THR - Holding Reg */
+ volatile uchar ier; /* WR IER - Interrupt Enable Reg */
+ volatile uchar isr_fcr; /* WR ISR/FCR - Interrupt Status Reg/Fifo Control Reg */
+ volatile uchar lcr; /* WR LCR - Line Control Reg */
+ volatile uchar mcr; /* WR MCR - Modem Control Reg */
+ volatile uchar lsr; /* WR LSR - Line Status Reg */
+ volatile uchar msr; /* WR MSR - Modem Status Reg */
+ volatile uchar spr; /* WR SPR - Scratch Pad Reg */
+ volatile uchar fctr; /* WR FCTR - Feature Control Reg */
+ volatile uchar efr; /* WR EFR - Enhanced Function Reg */
+ volatile uchar tfifo; /* WR TXCNT/TXTRG - Transmit FIFO Reg */
+ volatile uchar rfifo; /* WR RXCNT/RXTRG - Recieve FIFO Reg */
+ volatile uchar
PCI: remove pci_find_device usage from pci sysfs code.
ChangeSet 1.1998.11.23, 2005/02/25 08:26:11-08:00, [EMAIL PROTECTED] PCI: remove pci_find_device usage from pci sysfs code. Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> drivers/pci/pci-sysfs.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -Nru a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c --- a/drivers/pci/pci-sysfs.c 2005-03-04 12:41:33 -08:00 +++ b/drivers/pci/pci-sysfs.c 2005-03-04 12:41:33 -08:00 @@ -481,7 +481,7 @@ struct pci_dev *pdev = NULL; sysfs_initialized = 1; - while ((pdev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, pdev)) != NULL) + while ((pdev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, pdev)) != NULL) pci_create_sysfs_dev_files(pdev); return 0; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Fri, 4 Mar 2005, Linus Torvalds wrote: > > > On Fri, 4 Mar 2005, Nicolas Pitre wrote: > > > > It might still be worth a try, especially since so many people are > > convinced this is the way to go (your fault or not is not the point). > > Making releases is actually a fair bit of work. Not the script itself, but > just deciding and trying to synchronize. The fatc that people won't really > appreciate it anyway, and just complain about "that's not stable anyway" > just makes me even less interested. Don't read me wrong. It's not the work that is being done which is the problem. To the contrary, the current process is really great and for one I hope 2.7.x will _never_ happen, and here's why: Coming from the embedded world I can tell you that 2.5.x was simply too "instable" to use as a basis for a product, and communities around non i386 architectures simply don't have enough man power to follow two kernel trees (2.4.x and 2.5.x) in parallel. The embedded world therefore ended up developing on 2.4.x only because that was the stable tree that could bring revenues to sustain said development, even if 2.4.x was a dead end. Now the catch up phase on 2.6.x within the embedded world is almost done and 2.6.x is also where the major developments are happening. It's therefore way easier for smaller communities to stay in the game since 2.6.x is also stable enough for commercial products despite the rapid development actually occurring there. There are certainly a few more stability glitches than you could have found in 2.4.x but overall 2.6.x is a much better compromise bringing much more value to us -- thanks to your hard work and Andrew's (and RMK's) and everybody else for making the current process so efficient and dynamic. Now back to the current discussion. What people are complaining about is the lack of testing on the official 2.6.x releases. This lack of testing comes from the fact that your -rc releases are not seen like stable enough for the mass to test, and this is due mainly because the people outside of the development loop have no idea when you actually called for a patch calm down. It's not like you don't actually call for a calm down in order to have a release stabilized because, as Andrew pointed out, you effectively only merged true bug fixes into 2.6.11-rc[45]. See? You _do_ it and you _did_ it already. The only issue is to actually have way more people to jump in and try out kernels which are in that "calm down" phase. And for that to happen you need a clear signal to the people outside the development loop who currently can't trust your -rc releases since they end up including more than just bug fixes up to a randomly chosen particular -rc. That's why many are suggesting that you consider switching to -pre releases for developer sync points, and for the last -pre release where you call for a calm down. Then subsequent releases are -rc releases with strictly bug fixes. For example, 2.6.11-rc[123] would have been 2.6.11-pre[123] and 2.6.11-rc[45] would have been 2.6.11-rc[12]. See how this won't change anything to your work methodology besides the naming? And this has the potential of bringing more testers not closely following lkml or the commit log (granted that -rc becomes real release-candidate-bug_fix_only releases but again you do that already) since they'll see those -rc releases as nearly official releases. Of course it might not bring the hoped result but it costs nothing to try it out. That's what I meant in my previous email. P.S.: this is not incompatible with the "sucker" tree -- in fact both of those things might be useful and effective for their own purpose. Nicolas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11.1
On Fri, Mar 04, 2005 at 01:54:02PM -0800, Andrew Morton wrote: > Greg KH <[EMAIL PROTECTED]> wrote: > > > > On Fri, Mar 04, 2005 at 01:15:37PM -0800, Andrew Morton wrote: > > > Greg KH <[EMAIL PROTECTED]> wrote: > > > > > > > > > Here's the list of things which we might choose to put into 2.6.11.2. > > > > > I was > > > > > planning on sending them in for 2.6.12 when that was going to be > > > > > errata-only. > > > > > > > > Ok, care to forward them on? > > > > > > Sure. How do they get to Linus? > > > > Hm, either he pulls them from our new 2.6.x.y tree, or they go to him > > through you. Either way, I'd recommend sending them to him for now, > > We can do that. As long as the patches remain unaltered I assume that BK > will recognise that the patch is already there, in a different cset? Yes, it can handle such a merge just fine. > > until we get this whole "procedure" worked out. > > Yup. That's why I'm running this little experiment. Applying stimuli and > seeing how we respond. Yum, cheese. /me scampers off into the corner... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New ALPS code in -mm
On Fri, Mar 04, 2005 at 10:02:03PM +0100, Benoit Boissinot wrote:
> On Tue, 1 Mar 2005 12:54:32 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> >
> > Can you check with a current -mm kernel whether any of the issues is
> > still there? Everything seems to work smoothly with my ALPS.
> >
>
> I have problems with ALPS and 2.6.11-mm1. If I move the pointer with
> the touchpad, it activates button modifiers at the same time. (xev
> reports a MotionNotify event with state = 0x600 or sometimes 0x200
> instead of the expected 0x0).
>
> Moreover the pointer sometimes jump at the bottom right of the screen.
>
> It worked fine with 2.6.11-rc5-mm1.
>
> relevant portion of dmesg:
>
> - with rc5:
>
> Linux version 2.6.11-rc5-mm1 ([EMAIL PROTECTED]) (gcc version
> 3.4.3-20050110 (Gentoo Linux 3.4.3.20050110,
> ssp-3.4.3.20050110-0, pie-8.7.7)) #2 Tue Mar 1 13:33:05 CET 2005
> input: AT Translated Set 2 keyboard on isa0060/serio0
> ALPS Touchpad (Dualpoint) detected
> Enabling hardware tapping
> input: AlpsPS/2 ALPS TouchPad on isa0060/serio1
>
> - with .11
>
> Linux version 2.6.11-mm1 ([EMAIL PROTECTED]) (gcc version 3.4.3-20050110
> (Gentoo Linux 3.4.3.20050110, ssp-3.4.3.20050110-0,
> pie-8.7.7)) #5 Fri Mar 4 16:49:47 CET 2005
> input: AT Translated Set 2 keyboard on isa0060/serio0
>Enabling hardware tapping
> input: DualPoint Stick on isa0060/serio1
> input: AlpsPS/2 ALPS DualPoint TouchPad on isa0060/serio1
>
> I hope it can help.
Can you check if this patch helps?
[EMAIL PROTECTED], 2005-03-04 20:19:05+01:00, [EMAIL PROTECTED]
input: Fix inverted conditions in ALPS DualPoint stick packet
decoding.
[EMAIL PROTECTED], 2005-03-04 21:55:23+01:00, [EMAIL PROTECTED]
input: Fix ALPS DualPoint stick buttons. Testing shows that they're
at the same place as the pad ones, but packet has z==127.
alps.c | 26 +---
1 files changed, 10 insertions(+), 16 deletions(-)
diff -Nru a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
--- a/drivers/input/mouse/alps.c2005-03-04 22:00:33 +01:00
+++ b/drivers/input/mouse/alps.c2005-03-04 22:00:33 +01:00
@@ -124,8 +124,8 @@
/* Relative movement packet */
if (z == 127) {
- input_report_rel(dev2, REL_X, (x > 383 ? x : (x -
768)));
- input_report_rel(dev2, REL_Y, -(y > 255 ? y : (x -
512)));
+ input_report_rel(dev2, REL_X, (x > 383 ? (x - 768) :
x));
+ input_report_rel(dev2, REL_Y, -(y > 255 ? (x - 512) :
y));
input_sync(dev2);
return;
}
diff -Nru a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
--- a/drivers/input/mouse/alps.c2005-03-04 22:00:49 +01:00
+++ b/drivers/input/mouse/alps.c2005-03-04 22:00:49 +01:00
@@ -115,20 +115,14 @@
ges = packet[2] & 1;
fin = packet[2] & 2;
- /* Dualpoint has stick buttons in byte 0 */
- if (priv->i->flags & ALPS_DUALPOINT) {
-
- input_report_key(dev2, BTN_LEFT,packet[0] & 1);
- input_report_key(dev2, BTN_MIDDLE, (packet[0] >> 2) & 1);
- input_report_key(dev2, BTN_RIGHT, (packet[0] >> 1) & 1);
-
- /* Relative movement packet */
- if (z == 127) {
- input_report_rel(dev2, REL_X, (x > 383 ? (x - 768) :
x));
- input_report_rel(dev2, REL_Y, -(y > 255 ? (x - 512) :
y));
- input_sync(dev2);
- return;
- }
+ if ((priv->i->flags & ALPS_DUALPOINT) && z == 127) {
+ input_report_key(dev2, BTN_LEFT, left);
+ input_report_key(dev2, BTN_RIGHT, right);
+ input_report_key(dev2, BTN_MIDDLE, middle);
+ input_report_rel(dev2, REL_X, (x > 383 ? (x - 768) : x));
+ input_report_rel(dev2, REL_Y, -(y > 255 ? (x - 512) : y));
+ input_sync(dev2);
+ return;
}
/* Convert hardware tap to a reasonable Z value */
--
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] inotify for 2.6.11
On Fri, 04 Mar 2005 13:37:24 -0500, Robert Love <[EMAIL PROTECTED]> wrote: > Below is inotify, diffed against 2.6.11. > > I greatly reworked much of the data structures and their interactions, > to lay the groundwork for sanitizing the locking. I then, I hope, > sanitized the locking. It looks right, I am happy. Comments welcome. > I surely could of missed something. Maybe even something big. > > But, regardless, this release is a huge jump from the previous, fixing > all known issues and greatly improving the locking. > > Best, > > Robert Love Hey Robert, Are there plans of reworking the "generic" hooking infrastructure (fsnotify.h) to be more like the security hooking framework (+ stacking)? I think it'd be nice to be able to have a fs_notify struct of function pointers, point at the one's I've chosen to implement, and then register / unregister with the framework. Maybe this is an overly complicated approach, but these don't seem like they're generic hooks in anyway. + * include/linux/fs_notify.h - >generic< hooks for filesystem notification, to + * reduce in-source duplication from both >dnotify and inotify<. I guess I don't fully understand that comment. Just quickly glancing at it, all you've done is added a level of indirection and shifted the same redundant code from the VFS to fs_notify.h -- Please correct me if I'm wrong (not at all uncommon). As you already know, there's work being done on the audit subsystem that also needs notifications from the filesystem and would require yet another set of hooks. However, where we get notified might differ from where inotify and dnotify get notified and it seems like fs_notify is tailored specifically for inotify (and accommodates dnotify out of obligation) and openly implements the "generic" hooks it requires. Regardless, if this is the way it's going to be done. We'll expand fs_notify.h to meet our needs as well. Also, FYI: I just purchased the 2nd edition of your book, looking forward to reading it. -- - Timothy R. Chavez - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11.1
On Fri, Mar 04, 2005 at 02:34:22PM -0600, Ian Pilcher wrote: > From a purely process point of view, my concern would be making sure > that everything that goes into 2.6.X.Y (e.g. 2.6.11.1) makes it into > 2.6.X+1 (e.g. 2.6.12). It will be so. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: slab corruption in skb allocs
Matt Mackall wrote: Doh. 'ethtool -k' is what's needed, sorry. doh myself. :) this won't be very helpful though, as i get the same on all machines (with both drivers): Offload parameters for eth0: Cannot get device rx csum settings: Operation not supported Cannot get device tx csum settings: Operation not supported Cannot get device scatter-gather settings: Operation not supported Cannot get device tcp segmentation offload settings: Operation not supported no offload info available ethtool -k eth0 rx off tx off ditto. i'll try to reproduce this on a machine with e1000 though... cheers richard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] NFS can be selected without exportfs
Hi. NFS depends on ExportFS, and could do with a SELECT in the Kconfig. Without it compilation fails. Quote from Peter: "I get an error while compiling, the same config worked for earlier releases for 2.6.11-rc2. applied patches: 2.6.11-rc3 swsusp2 2.1.6 for 2.6.11-rc3 OS: debian unstable gcc version: gcc (GCC) 3.3.5 (Debian 1:3.3.5-8) LD init/built-in.o LD .tmp_vmlinux1 fs/built-in.o(.text+0x7329f): In function `fh_verify': : undefined reference to `export_op_default' fs/built-in.o(.text+0x738b7): In function `fh_compose': : undefined reference to `export_op_default' fs/built-in.o(.text+0x73bb7): In function `fh_update': : undefined reference to `export_op_default' fs/built-in.o(.text+0x73e80): In function `_fh_update': : undefined reference to `export_op_default' fs/built-in.o(.text+0x78150): In function `check_export': : undefined reference to `find_exported_dentry' make[1]: *** [.tmp_vmlinux1] Error 1 thx Peter" Submitted-By: Peter Frühberger <[EMAIL PROTECTED]> Signed-Off-By: Nigel Cunningham <[EMAIL PROTECTED]> diff -ruNp 990-select-exportfs-on-nfs-server-old/fs/Kconfig 990-select-exportfs-on-nfs-server-new/fs/Kconfig --- 990-select-exportfs-on-nfs-server-old/fs/Kconfig2005-02-03 22:33:40.0 +1100 +++ 990-select-exportfs-on-nfs-server-new/fs/Kconfig2005-02-06 08:22:25.0 +1100 @@ -1400,6 +1400,7 @@ config NFSD tristate "NFS server support" depends on INET select LOCKD + select EXPORTFS select SUNRPC help If you want your Linux box to act as an NFS *server*, so that other -- Nigel Cunningham Software Engineer, Canberra, Australia http://www.cyclades.com Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028; Mob: +61 (417) 100 574 Maintainer of Suspend2 Kernel Patches http://softwaresuspend.berlios.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.11-rc4: Alps touchpad too slow
My Vaio r505te comes up with an unusably slow touchpad if I allow the ALPS driver to drive it. It says > ALPS Touchpad (Glidepoint) detected > Disabling hardware tapping > input: AlpsPS/2 ALPS TouchPad on isa0060/serio1 and then the trackpad operates at about 1/8 the speed I've gotten used to. I'm running 2.6.11-rc4; this started happening somewhere between 2.6.10 and 2.6.11-rc3. I've toyed with 'xset m', but nothing I've done there seems to have any effect. (I suspect that Linux never generates the appropriate sequence of mouse events to trigger the X cursor acceleration regime.) I can restore the original behavior by passing "proto=exps" to psmouse.o, in which case I get > input: PS/2 Generic Mouse on isa0060/serio1 On a related note, how are users supposed to control this newfangled PS2 driver? I'd like at least the *option* to turn tapping back on, but I can't find any knobs *anywhere*. And of course I'd like to adjust the tracking speed, too. -andy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] inotify for 2.6.11
On Fri, 2005-03-04 at 15:38 -0600, Timothy R. Chavez wrote: Hi, Mr. Chavez. > Are there plans of reworking the "generic" hooking infrastructure > (fsnotify.h) to be more like the security hooking framework (+ > stacking)? I think it'd be nice to be able to have a fs_notify struct > of function pointers, point at the one's I've chosen to implement, and > then register / unregister with the framework. Maybe this is an > overly complicated approach, but these don't seem like they're generic > hooks in anyway. Personally, I think it is overkill. I don't think we are going to have the myriad of file notification systems that we have for security layers (indeed, the goal is to have just inotify). That said, we could always make the layer more pluggable once inotify is in. I would not fight that. But, personally I don't see any real benefit, just additional complexity and overhead. > + * include/linux/fs_notify.h - >generic< hooks for filesystem notification, > to > + * reduce in-source duplication from both >dnotify and inotify<. > > I guess I don't fully understand that comment. Just quickly glancing > at it, all you've done is added a level of indirection and shifted the > same redundant code from the VFS to fs_notify.h -- Please correct me > if I'm wrong (not at all uncommon). No, you are right. The "generic" part is supposed to be what is in the VFS. E.g., the fsnotify_foo() calls are supposed to be the generic interface. The body of these calls, as you can see, is static code, a simple copy and cleanup of the inotify + dnotify hooks. The idea, spurred by Christoph Hellwig's suggestion, was to keep the VFS clean. Not make a super neat pluggable notification system. I think the layers ARE generic, though, in the sense that foonotify could probably drop some static code into fsnotify.h and work. > As you already know, there's work being done on the audit subsystem > that also needs notifications from the filesystem and would require > yet another set of hooks. However, where we get notified might differ > from where inotify and dnotify get notified and it seems like > fs_notify is tailored specifically for inotify (and accommodates > dnotify out of obligation) and openly implements the "generic" hooks > it requires. > > Regardless, if this is the way it's going to be done. We'll expand > fs_notify.h to meet our needs as well. If we end up duplicating stuff and making a big mess, then the audit layer and the notification layer should DEFINITELY look at merging and consolidating. But I think that we need to wait until one or the other gets more traction and into the mainline kernel. > Also, FYI: > I just purchased the 2nd edition of your book, looking forward to reading it. Great. Hope you enjoy it! ;-) Best, Robert Love - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: slab corruption in skb allocs
_correction_ to my previous mail, this does _not_ happen with the eepro100 driver. (sorry for the confusion, i got the kernel images mixed up with all the testing i've been doing.) could this affect the e1000 driver as well? Matt Mackall wrote: Send the output of ethtool, please. box 1, affected: Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 1 Transceiver: internal Auto-negotiation: on Current message level: 0x20c1 (8385) Link detected: yes box 2, affected: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: g Wake-on: g Current message level: 0x0007 (7) Link detected: yes box 3, not affected: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: g Wake-on: g Current message level: 0x0007 (7) Link detected: yes This tends to be checksum offloading not working as it should or the like. Can you repeat this with bulk ssh traffic? yes, with various strange effects: Received disconnect from 195.58.172.154: 2: Bad packet length 919251405. or Received disconnect from 195.58.172.154: 2: Corrupted MAC on input. cheers richard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11.1
On Fri, Mar 04, 2005 at 01:51:13PM -0800, Andrew Morton wrote: > Jeff Garzik <[EMAIL PROTECTED]> wrote: > > > > > cramfs-small-stat2-fix.patch > > > setup_per_zone_lowmem_reserve-oops-fix.patch > > > dv1394-ioctl-retval-fix.patch > > > ppc32-compilation-fixes-for-ebony-luan-and-ocotea.patch > > > nfsd--sgi-921857-find-broken-with-nohide-on-nfsv3.patch > > > nfsd--exportfs-reduce-stack-usage.patch > > > > Unless it's crashing for people, stack usage is IMO a wanted-fix not > > needed-fix. > > Sure. The patch is bog-obvious though. > > > > > > nfsd--svcrpc-add-a-per-flavor-set_client-method.patch > > > > is this critical? > > Doubt it, unless the succeeding patches have a dependency on it. But the > other patches have not been tested without this one being present. > > > These patches have been in mm for four weeks, so it's probably OK from a > stability POV to take them straight into linux-release. If they were > fresher then the way to handle them would be to merge them into Linus's > tree and backport in a couple of weeks time. Cool, fair enough. linux-release sounds fine. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] I2C: Kill i2c_client.id (3/5)
ChangeSet 1.2085, 2005/03/02 11:52:31-08:00, [EMAIL PROTECTED]
[PATCH] I2C: Kill i2c_client.id (3/5)
(3/5) Stop using i2c_client.id in misc drivers.
Affected drivers:
* acorn/char/pcf8583
* acorn/char/i2c
* i2c/i2c-dev
* macintosh/therm_windtunnel
* sound/oss/dmasound/dac3550a
* sound/ppc/keywest
The Acorn pcf8583 driver would give the i2c_client id the same value as
the i2c_driver id, and later test that client id (in i2c). I changed it
to test the client's driver id instead. The result is the same and the
client id is then useless and can be removed.
All other drivers here would allocate the client id to some value and
then never use it. They are unaffected by the change.
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/acorn/char/i2c.c |2 +-
drivers/acorn/char/pcf8583.c |1 -
drivers/i2c/i2c-dev.c|1 -
drivers/macintosh/therm_windtunnel.c |4
sound/oss/dmasound/dac3550a.c|4
sound/ppc/keywest.c |2 --
6 files changed, 1 insertion(+), 13 deletions(-)
diff -Nru a/drivers/acorn/char/i2c.c b/drivers/acorn/char/i2c.c
--- a/drivers/acorn/char/i2c.c 2005-03-04 12:26:11 -08:00
+++ b/drivers/acorn/char/i2c.c 2005-03-04 12:26:11 -08:00
@@ -313,7 +313,7 @@
static int ioc_client_reg(struct i2c_client *client)
{
- if (client->id == I2C_DRIVERID_PCF8583 &&
+ if (client->driver->id == I2C_DRIVERID_PCF8583 &&
client->addr == 0x50) {
struct rtc_tm rtctm;
unsigned int year;
diff -Nru a/drivers/acorn/char/pcf8583.c b/drivers/acorn/char/pcf8583.c
--- a/drivers/acorn/char/pcf8583.c 2005-03-04 12:26:11 -08:00
+++ b/drivers/acorn/char/pcf8583.c 2005-03-04 12:26:11 -08:00
@@ -51,7 +51,6 @@
return -ENOMEM;
memset(c, 0, sizeof(*c));
- c->id = pcf8583_driver.id;
c->addr = addr;
c->adapter = adap;
c->driver = _driver;
diff -Nru a/drivers/i2c/i2c-dev.c b/drivers/i2c/i2c-dev.c
--- a/drivers/i2c/i2c-dev.c 2005-03-04 12:26:11 -08:00
+++ b/drivers/i2c/i2c-dev.c 2005-03-04 12:26:11 -08:00
@@ -507,7 +507,6 @@
static struct i2c_client i2cdev_client_template = {
.name = "I2C /dev entry",
- .id = 1,
.addr = -1,
.driver = _driver,
};
diff -Nru a/drivers/macintosh/therm_windtunnel.c
b/drivers/macintosh/therm_windtunnel.c
--- a/drivers/macintosh/therm_windtunnel.c 2005-03-04 12:26:11 -08:00
+++ b/drivers/macintosh/therm_windtunnel.c 2005-03-04 12:26:11 -08:00
@@ -47,8 +47,6 @@
#define LOG_TEMP 0 /* continously log
temperature */
#define I2C_DRIVERID_G4FAN 0x9001 /* fixme */
-#define THERMOSTAT_CLIENT_ID 1
-#define FAN_CLIENT_ID 2
static int do_probe( struct i2c_adapter *adapter, int
addr, int kind);
@@ -372,7 +370,6 @@
goto out;
printk("ADM1030 fan controller [EMAIL PROTECTED]", cl->addr );
- cl->id = FAN_CLIENT_ID;
strlcpy( cl->name, "ADM1030 fan controller", sizeof(cl->name) );
if( !i2c_attach_client(cl) )
@@ -412,7 +409,6 @@
x.overheat_temp = os_temp;
x.overheat_hyst = hyst_temp;
- cl->id = THERMOSTAT_CLIENT_ID;
strlcpy( cl->name, "DS1775 thermostat", sizeof(cl->name) );
if( !i2c_attach_client(cl) )
diff -Nru a/sound/oss/dmasound/dac3550a.c b/sound/oss/dmasound/dac3550a.c
--- a/sound/oss/dmasound/dac3550a.c 2005-03-04 12:26:11 -08:00
+++ b/sound/oss/dmasound/dac3550a.c 2005-03-04 12:26:11 -08:00
@@ -40,9 +40,6 @@
static int daca_detect_client(struct i2c_adapter *adapter, int address);
static int daca_detach_client(struct i2c_client *client);
-/* Unique ID allocation */
-static int daca_id;
-
struct i2c_driver daca_driver = {
.owner = THIS_MODULE,
.name = "DAC3550A driver V " DACA_VERSION,
@@ -176,7 +173,6 @@
new_client->driver = _driver;
new_client->flags = 0;
strcpy(new_client->name, client_name);
- new_client->id = daca_id++; /* racy... */
if (daca_init_client(new_client))
goto bail;
diff -Nru a/sound/ppc/keywest.c b/sound/ppc/keywest.c
--- a/sound/ppc/keywest.c 2005-03-04 12:26:11 -08:00
+++ b/sound/ppc/keywest.c 2005-03-04 12:26:11 -08:00
@@ -76,8 +76,6 @@
new_client->flags = 0;
strcpy(i2c_device_name(new_client), keywest_ctx->name);
-
- new_client->id = keywest_ctx->id++; /* Automatically unique */
keywest_ctx->client = new_client;
/* Tell the i2c layer a new client has arrived */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
[PATCH] I2C: w83627hf needs i2c-isa
ChangeSet 1.2113, 2005/03/02 15:03:48-08:00, [EMAIL PROTECTED] [PATCH] I2C: w83627hf needs i2c-isa The w83627hf driver is useless unless i2c-isa is present. All other drivers in this case do select I2C_ISA through Kconfig, so this one should as well do. Signed-off-by: Jean Delvare <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> drivers/i2c/chips/Kconfig |1 + 1 files changed, 1 insertion(+) diff -Nru a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig --- a/drivers/i2c/chips/Kconfig 2005-03-04 12:22:59 -08:00 +++ b/drivers/i2c/chips/Kconfig 2005-03-04 12:22:59 -08:00 @@ -338,6 +338,7 @@ tristate "Winbond W83627HF, W83627THF, W83637HF, W83697HF" depends on I2C && EXPERIMENTAL select I2C_SENSOR + select I2C_ISA help If you say yes here you get support for the Winbond W836X7 series of sensor chips: the W83627HF, W83627THF, W83637HF, and the W83697HF - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11.1
Jeff Garzik <[EMAIL PROTECTED]> wrote: > > > cramfs-small-stat2-fix.patch > > setup_per_zone_lowmem_reserve-oops-fix.patch > > dv1394-ioctl-retval-fix.patch > > ppc32-compilation-fixes-for-ebony-luan-and-ocotea.patch > > nfsd--sgi-921857-find-broken-with-nohide-on-nfsv3.patch > > nfsd--exportfs-reduce-stack-usage.patch > > Unless it's crashing for people, stack usage is IMO a wanted-fix not > needed-fix. Sure. The patch is bog-obvious though. > > > nfsd--svcrpc-add-a-per-flavor-set_client-method.patch > > is this critical? Doubt it, unless the succeeding patches have a dependency on it. But the other patches have not been tested without this one being present. These patches have been in mm for four weeks, so it's probably OK from a stability POV to take them straight into linux-release. If they were fresher then the way to handle them would be to merge them into Linus's tree and backport in a couple of weeks time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BK PATCH] W1 patches for 2.6.11
Hi, Here are some W1 driver patches against the latest 2.6.11 tree. These have all been in the past few -mm releases. Please pull from: bk://kernel.bkbits.net/gregkh/linux/w1-2.6 thanks, greg k-h drivers/w1/dscore.c| 27 ++- drivers/w1/dscore.h|3 --- drivers/w1/matrox_w1.c |2 +- drivers/w1/w1.c| 41 +++-- drivers/w1/w1.h|1 - drivers/w1/w1_family.c |4 ++-- drivers/w1/w1_int.c|4 drivers/w1/w1_therm.c | 12 ++-- 8 files changed, 38 insertions(+), 56 deletions(-) - Christophe Lucas: o drivers/w1/*: convert to pci_register_driver Evgeniy Polyakov: o w1: get rid of the potential problems with atomic operations o w1: replace obsoleted *sleep_on* o w1: Core cleanup 1/2 o w1: dscore cleanups. 2/2 Greg Kroah-Hartman: o w1: fix some compiler warnings generated by the last "static" patch Nishanth Aravamudan: o w1/w1_therm: replace schedule_timeout() with msleep_interruptible() - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: swsusp: allow resume from initramfs
Hi! > > > I don't understand how this can be affected by the modularness of the > > > kernel. Can you explain a little more? > > > > > > Would it not be simpler to just add "resume=03:02" to the boot command > > > line? > > > > In addition to what others have mentioned, there's also the situation > > where swap is on a logical volume. In that case, the initramfs needs to > > get LVM up and running before you can even think about resuming. > > > > Swap on a logical volume is the default Fedora Core 3 partition layout, > > and I imagine it's the default for Red Hat Enterprise Linux 4 as well. > > You guys are reinventing the wheel a lot at the moment and I'm in the > middle of doing it for x86_64 lowlevel code :> Can we see if we can work > a little more closely - perhaps we can get some shared code going that > will allow us to handle these issues without stepping on each others' > feet? In particular, shared code for > > - initramfs and initrd support Its actually done, and it was few strategically placed lines of code (like 20 lines). I do not think it can be meaningfully shared. > - lowlevel suspend & resume This makes very good sense to share. We have i386, x86-64 and ppc versions. They simply walk list of pbe's; that should be simple enough to be usable for suspend2, too Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11.1
Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > > On Fri, 4 Mar 2005, Andrew Morton wrote: > > > > > > Ok, care to forward them on? > > > > Sure. How do they get to Linus? > > I'll just pull from the sucker-tree. > That tree has the not-for-linus raid6 fix and the not-for-linus i8042 fix. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 2/5] setup_per_zone_lowmem_reserve() oops fix
If you do 'echo 0 0 > /proc/sys/vm/lowmem_reserve_ratio' the kernel gets a
divide-by-zero.
Prevent that, and fiddle with some whitespace too.
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/mm/page_alloc.c | 21 +++--
1 files changed, 15 insertions(+), 6 deletions(-)
diff -puN mm/page_alloc.c~setup_per_zone_lowmem_reserve-oops-fix mm/page_alloc.c
--- 25/mm/page_alloc.c~setup_per_zone_lowmem_reserve-oops-fix 2005-03-04
13:16:10.0 -0800
+++ 25-akpm/mm/page_alloc.c 2005-03-04 13:16:10.0 -0800
@@ -37,13 +37,17 @@
#include
#include "internal.h"
-/* MCD - HACK: Find somewhere to initialize this EARLY, or make this
initializer cleaner */
+/*
+ * MCD - HACK: Find somewhere to initialize this EARLY, or make this
+ * initializer cleaner
+ */
nodemask_t node_online_map = { { [0] = 1UL } };
nodemask_t node_possible_map = NODE_MASK_ALL;
struct pglist_data *pgdat_list;
unsigned long totalram_pages;
unsigned long totalhigh_pages;
long nr_swap_pages;
+
/*
* results with 256, 32 in the lowmem_reserve sysctl:
* 1G machine -> (16M dma, 800M-16M normal, 1G-800M high)
@@ -1924,15 +1928,20 @@ static void setup_per_zone_lowmem_reserv
for_each_pgdat(pgdat) {
for (j = 0; j < MAX_NR_ZONES; j++) {
- struct zone * zone = pgdat->node_zones + j;
+ struct zone *zone = pgdat->node_zones + j;
unsigned long present_pages = zone->present_pages;
zone->lowmem_reserve[j] = 0;
for (idx = j-1; idx >= 0; idx--) {
- struct zone * lower_zone = pgdat->node_zones +
idx;
+ struct zone *lower_zone;
+
+ if (sysctl_lowmem_reserve_ratio[idx] < 1)
+ sysctl_lowmem_reserve_ratio[idx] = 1;
- lower_zone->lowmem_reserve[j] = present_pages /
sysctl_lowmem_reserve_ratio[idx];
+ lower_zone = pgdat->node_zones + idx;
+ lower_zone->lowmem_reserve[j] = present_pages /
+ sysctl_lowmem_reserve_ratio[idx];
present_pages += lower_zone->present_pages;
}
}
@@ -2039,7 +2048,7 @@ module_init(init_per_zone_pages_min)
* changes.
*/
int min_free_kbytes_sysctl_handler(ctl_table *table, int write,
- struct file *file, void __user *buffer, size_t *length, loff_t
*ppos)
+ struct file *file, void __user *buffer, size_t *length, loff_t *ppos)
{
proc_dointvec(table, write, file, buffer, length, ppos);
setup_per_zone_pages_min();
@@ -2056,7 +2065,7 @@ int min_free_kbytes_sysctl_handler(ctl_t
* if in function of the boot time zone sizes.
*/
int lowmem_reserve_ratio_sysctl_handler(ctl_table *table, int write,
-struct file *file, void __user *buffer, size_t *length, loff_t
*ppos)
+ struct file *file, void __user *buffer, size_t *length, loff_t *ppos)
{
proc_dointvec_minmax(table, write, file, buffer, length, ppos);
setup_per_zone_lowmem_reserve();
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pci/quirks.c: unhide SMBus device on Samsung P35 laptop
ChangeSet 1.1998.11.20, 2005/02/17 15:06:37-08:00, [EMAIL PROTECTED]
[PATCH] pci/quirks.c: unhide SMBus device on Samsung P35 laptop
this patch is needed to make the SMBus device on my Samsung P35
laptop visible. By default, it doesn't appear as a pci device.
Patch tested, works perfectly for me. Please apply.
Signed-off-by: Carl-Daniel Hailfinger <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/pci/quirks.c|6 ++
include/linux/pci_ids.h |2 ++
2 files changed, 8 insertions(+)
diff -Nru a/drivers/pci/quirks.c b/drivers/pci/quirks.c
--- a/drivers/pci/quirks.c 2005-03-04 12:41:55 -08:00
+++ b/drivers/pci/quirks.c 2005-03-04 12:41:55 -08:00
@@ -807,6 +807,12 @@
case 0x0001: /* Toshiba Satellite A40 */
asus_hides_smbus = 1;
}
+ } else if (unlikely(dev->subsystem_vendor == PCI_VENDOR_ID_SAMSUNG)) {
+ if (dev->device == PCI_DEVICE_ID_INTEL_82855PM_HB)
+ switch(dev->subsystem_device) {
+ case 0xC00C: /* Samsung P35 notebook */
+ asus_hides_smbus = 1;
+ }
}
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82845_HB,
asus_hides_smbus_hostbridge );
diff -Nru a/include/linux/pci_ids.h b/include/linux/pci_ids.h
--- a/include/linux/pci_ids.h 2005-03-04 12:41:55 -08:00
+++ b/include/linux/pci_ids.h 2005-03-04 12:41:55 -08:00
@@ -1905,6 +1905,8 @@
#define PCI_DEVICE_ID_OXSEMI_16PCI954PP0x9513
#define PCI_DEVICE_ID_OXSEMI_16PCI952 0x9521
+#define PCI_VENDOR_ID_SAMSUNG 0x144d
+
#define PCI_VENDOR_ID_AIRONET 0x14b9
#define PCI_DEVICE_ID_AIRONET_4800_1 0x0001
#define PCI_DEVICE_ID_AIRONET_4800 0x4500 // values switched? see
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
useless check in port-allocation code?
Hi,
In the 2.6.11 code, I found this:
static int tcp_v6_get_port(struct sock *sk, unsigned short snum)
also in:
static int tcp_v4_get_port(struct sock *sk, unsigned short snum)
{
...
if (snum == 0) {
int low = sysctl_local_port_range[0];
int high = sysctl_local_port_range[1];
spin_lock(_portalloc_lock);
rover = tcp_port_rover;
do {rover++;
if ((rover < low) || (rover > high))
rover = low;
Now I wonder: is that 'rover < low' check not redundant?
ints are bigger then the maximum portnumber (65535) so when
rover++ gets too high, the check for 'rover > high' will truncate
it to low (in the next line) waaay before the int itself wraps.
Maybe it is needed because tcp_port_rover is < low before the
function starts, in that case the check for high)
+ if (rover > high)
rover = low;
head = _bhash[tcp_bhashfn(rover)];
spin_lock(>lock);
diff -uNr net/ipv6/tcp_ipv6.c.org net/ipv6/tcp_ipv6.c
--- net/ipv6/tcp_ipv6.c.org 2005-03-04 22:41:44.043007791 +0100
+++ net/ipv6/tcp_ipv6.c 2005-03-04 22:42:17.604728073 +0100
@@ -139,9 +139,12 @@
int rover;
spin_lock(_portalloc_lock);
- rover = tcp_port_rover;
+ if (tcp_port_rover < low)
+ rover = low;
+ else
+ rover = tcp_port_rover;
do {rover++;
- if ((rover < low) || (rover > high))
+ if (rover > high)
rover = low;
head = _bhash[tcp_bhashfn(rover)];
spin_lock(>lock);
Signed-off-by: Folkert van Heusden <[EMAIL PROTECTED]>
Folkert van Heusden
Op zoek naar een IT of Finance baan? Mail me voor de mogelijkheden!
+--+
|UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/)|
|a try, it brings monitoring logfiles to a different level! See|
|http://vanheusden.com/multitail/features.html for a feature list. |
+--= www.unixsoftware.nl =-+
Phone: +31-6-41278122, PGP-key: 1F28D8AE
Get your PGP/GPG key signed at www.biglumber.com!
signature.asc
Description: Digital signature
Re: RFD: Kernel release numbering
On Friday 04 March 2005 15:37, Linus Torvalds wrote: [...] >No. > >I used to do "-pre", a long time ago. Exactly because they were >synchronization points for developers. > >These days, that's pointless. We keep the tree in pretty good > working order (certainly as good as my -pre's ever were) > constantly, and developers who need to can synchronize with either > the BK tree or the nightly snapshots. The fact is, 99% of the > developers don't even need to do that, since most of the > development process is quite well parallellised by now, and there > is seldom any serious overlap. And I think your use of bitkeeper is largely responsible for that. >So the point of -pre's are gone. Have people actually _looked_ at > the -rc releases? They are very much done when I reach the point > and say "ok, let's calm down". The first one is usually pretty big > and often needs some fixing, simply because the first one is > _inevitably_ (and by design) the one that gets the pent-up demand > from the previous calming down period. > >But it's very much a call to "ok, guys, calm down now". > >And if you aren't calming down, it's _your_ problem. Complaining > about naming of -pre vs -rc is pointless. > >The even/odd situation would have made for a situation that some > people seem to be arguing for (more explicit calming-down period), > but with the difference that I think the odd ones should definitely > have been user-release quality already. But that one was apparently > hated by so many people that it's not even worth trying. > >The fact is, there is no perfect way of doing things, and this > discussion has degenerated into nothing but whining. Which is kind > of expected, but let's hope that the only non-whining that came out > of this (Greg & co's trials with 2.6.x.y) ends up being worthwhile. > > Linus One last Q I guess. When was the last time somebody flushed a bug out of forcedeth? I built a kernel last night after turning off the broken flag, and when I rebooted to it this morning I was surprised to see that because its still marked experimental, I had no networking. And when I went to turn that back on, I also had to go turn that back on seperately. IMO, no usefull purpose is achieved by keeping it experimental after the amount of time thats gone by with 1/4 of the world whose mobo has an NForce2 chipset on it, using that as their networking driver. My $0.02. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] I2C: add fscpos chip driver
ChangeSet 1.2080, 2005/03/02 11:04:17-08:00, [EMAIL PROTECTED]
[PATCH] I2C: add fscpos chip driver
This patch against 2.6.11-rc1 contains a driver for fscpos sensors.
Signed-off-by: Stefan Ott <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/i2c/chips/Kconfig | 11
drivers/i2c/chips/Makefile |1
drivers/i2c/chips/fscpos.c | 633 +
3 files changed, 645 insertions(+)
diff -Nru a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
--- a/drivers/i2c/chips/Kconfig 2005-03-04 12:26:46 -08:00
+++ b/drivers/i2c/chips/Kconfig 2005-03-04 12:26:46 -08:00
@@ -84,6 +84,17 @@
This driver can also be built as a module. If so, the module
will be called fscher.
+config SENSORS_FSCPOS
+ tristate "FSC Poseidon"
+ depends on I2C && EXPERIMENTAL
+ select I2C_SENSOR
+ help
+ If you say yes here you get support for Fujitsu Siemens
+ Computers Poseidon sensor chips.
+
+ This driver can also be built as a module. If so, the module
+ will be called fscpos.
+
config SENSORS_GL518SM
tristate "Genesys Logic GL518SM"
depends on I2C && EXPERIMENTAL
diff -Nru a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
--- a/drivers/i2c/chips/Makefile2005-03-04 12:26:46 -08:00
+++ b/drivers/i2c/chips/Makefile2005-03-04 12:26:46 -08:00
@@ -14,6 +14,7 @@
obj-$(CONFIG_SENSORS_DS1621) += ds1621.o
obj-$(CONFIG_SENSORS_EEPROM) += eeprom.o
obj-$(CONFIG_SENSORS_FSCHER) += fscher.o
+obj-$(CONFIG_SENSORS_FSCPOS) += fscpos.o
obj-$(CONFIG_SENSORS_GL518SM) += gl518sm.o
obj-$(CONFIG_SENSORS_IT87) += it87.o
obj-$(CONFIG_SENSORS_LM63) += lm63.o
diff -Nru a/drivers/i2c/chips/fscpos.c b/drivers/i2c/chips/fscpos.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/i2c/chips/fscpos.c2005-03-04 12:26:46 -08:00
@@ -0,0 +1,633 @@
+/*
+ fscpos.c - Kernel module for hardware monitoring with FSC Poseidon chips
+ Copyright (C) 2004, 2005 Stefan Ott <[EMAIL PROTECTED]>
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software
+ Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+*/
+
+/*
+ fujitsu siemens poseidon chip,
+ module based on the old fscpos module by Hermann Jung <[EMAIL
PROTECTED]> and
+ the fscher module by Reinhard Nissl <[EMAIL PROTECTED]>
+
+ original module based on lm80.c
+ Copyright (C) 1998, 1999 Frodo Looijaard <[EMAIL PROTECTED]>
+ and Philip Edelbrock <[EMAIL PROTECTED]>
+
+ Thanks to Jean Delvare for reviewing my code and suggesting a lot of
+ improvements.
+*/
+
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * Addresses to scan
+ */
+static unsigned short normal_i2c[] = { 0x73, I2C_CLIENT_END };
+static unsigned int normal_isa[] = { I2C_CLIENT_ISA_END };
+
+/*
+ * Insmod parameters
+ */
+SENSORS_INSMOD_1(fscpos);
+
+/*
+ * The FSCPOS registers
+ */
+
+#define DEBUG
+
+/* chip identification */
+#define FSCPOS_REG_IDENT_0 0x00
+#define FSCPOS_REG_IDENT_1 0x01
+#define FSCPOS_REG_IDENT_2 0x02
+#define FSCPOS_REG_REVISION0x03
+
+/* global control and status */
+#define FSCPOS_REG_EVENT_STATE 0x04
+#define FSCPOS_REG_CONTROL 0x05
+
+/* watchdog */
+#define FSCPOS_REG_WDOG_PRESET 0x28
+#define FSCPOS_REG_WDOG_STATE 0x23
+#define FSCPOS_REG_WDOG_CONTROL0x21
+
+/* voltages */
+#define FSCPOS_REG_VOLT_12 0x45
+#define FSCPOS_REG_VOLT_5 0x42
+#define FSCPOS_REG_VOLT_BATT 0x48
+
+/* fans - the chip does not support minimum speed for fan2 */
+static u8 FSCPOS_REG_PWM[] = { 0x55, 0x65 };
+static u8 FSCPOS_REG_FAN_ACT[] = { 0x0e, 0x6b, 0xab };
+static u8 FSCPOS_REG_FAN_STATE[] = { 0x0d, 0x62, 0xa2 };
+static u8 FSCPOS_REG_FAN_RIPPLE[] = { 0x0f, 0x6f, 0xaf };
+
+/* temperatures */
+static u8 FSCPOS_REG_TEMP_ACT[] = { 0x64, 0x32, 0x35 };
+static u8 FSCPOS_REG_TEMP_STATE[] = { 0x71, 0x81, 0x91 };
+
+/*
+ * Functions declaration
+ */
+static int fscpos_attach_adapter(struct i2c_adapter *adapter);
+static int fscpos_detect(struct i2c_adapter *adapter, int address, int kind);
+static int fscpos_detach_client(struct i2c_client *client);
+
+static int fscpos_read_value(struct
Re: RFD: Kernel release numbering
On Fri, Mar 04, 2005 at 02:22:19PM -0800, Andrew Morton wrote:
> That's now eight architectures I'll compile-test mm kernels on.
Cool, but please check whether this produces an error:
echo "mov r0, #foo" | arm-linux-as -o /dev/null -
you should get:
{standard input}: Assembler messages:
{standard input}:1: Error: undefined symbol foo used as an immediate value
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11.1
On Fri, 4 Mar 2005, Andrew Morton wrote: > > > > Ok, care to forward them on? > > Sure. How do they get to Linus? I'll just pull from the sucker-tree. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
"Richard Purdie" <[EMAIL PROTECTED]> wrote: > > As an experiment I ran "bitbake meta-sdk" on my copy of openemedded. A while > later I have these in the deploy directory amongst other things. > > http://www.rpsys.net/openzaurus/arm-cross/binutils-cross-sdk-2.15.91.0.2-r5.tar.gz > > (3.8MB) > http://www.rpsys.net/openzaurus/arm-cross/gcc-cross-sdk-3.4.2-r0.tar.gz > (17.5MB) Bless you. I just built an arm kernel! That compiler is *fast*. 47 seconds. Weird. For reference, untar the above in / and use #!/bin/sh export ARCH=arm export CROSS_COMPILE=arm-linux- W=/usr/local/arm/oe/bin MAKE="make" if [ -z "$1" ] then WHAT="vmlinux" else WHAT="$1" fi nr_cpus=$(grep processor /proc/cpuinfo|wc -l) j=$(expr $nr_cpus \* 3 / 2) MAKE_ARGS="ARCH=$ARCH CROSS_COMPILE=$W/arm-linux-" if [ x"$DISTCC_HOSTS" != x ] then $MAKE -j 12 CC="ccache distcc --ccache-skip $W/$CROSS_COMPILE""gcc" $MAKE_ARGS $WHAT 2>/tmp/log else $MAKE -j $j $MAKE_ARGS CC="$W/$CROSS_COMPILE""gcc" $WHAT 2>/tmp/log fi cat /tmp/log That's now eight architectures I'll compile-test mm kernels on. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11.1
On Fri, Mar 04, 2005 at 12:44:31PM -0800, Andrew Morton wrote: > wrt the nfsd patches, Neil said: > > The problem they fix is that currently: > Client A holds a lock > Client B tries to get the lock and blocks > Client A drops the lock > **Client B doesn't get the lock immediately, but has to wait for a >timeout. (several seconds) Sounds like a performance thing than "oh my god the world is falling apart" type thing. Given it recovers after a few seconds, is it worth it ? Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-mm1
Alexander Nyberg <[EMAIL PROTECTED]> wrote: > > fre 2005-03-04 klockan 03:32 -0800 skrev Andrew Morton: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11/2.6.11-mm1/ > > > > > > - Added the new bk-audit tree. Contains updates to the kernel's audit > > feature. Maintained by David Woodhouse. > > > > - The Dell keyboard problems should be fixed. Testing needed. > > > > - Dmitry's bk-dtor-input tree is no longer active and has been dropped. > > Just booted up a box and tried to log onto ssh which didn't worked so I > looked at kernel log and behold, 128MB box with no swap, had just > booted. Couldn't get any access after this. > A few kernel debugging options were chosen notably CONFIG_DEBUG_SLAB & > CONFIG_DEBUG_PAGEALLOC So you're saying that the box has run out of memory? Please send me the .config then disable CONFIG_DEBUG_PAGEALLOC and retest, thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFQ] Rules for accepting patches into the linux-releases tree
Anything else anyone can think of? Any objections to any of these? I based them off of Linus's original list. thanks, greg k-h -- Rules on what kind of patches are accepted, and what ones are not, into the "linux-release" tree. - It can not bigger than 100 lines, with context. - It must fix only one thing. - It must fix a real bug that bothers people (not a, "This could be a problem..." type thing.) - It must fix a problem that causes a build error (but not for things marked CONFIG_BROKEN), an oops, a hang, or a real security issue. - No "theoretical race condition" issues, unless an explanation of how the race can be exploited. - It can not contain any "trivial" fixes in it (spelling changes, whitespace cleanups, etc.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.6.11-mm1 "nobh" support for ext3 writeback mode
Andrew Morton <[EMAIL PROTECTED]> wrote: > > page reclaim can come in, grab the page lock and > whip the page off the mapping. No it can't - we hold an additional ref on the page, so reclaim will back off. Still, it feels a bit flakey. And we're not supposed to take lock_page() inside journal_start, because that's a ranking violation. Probably i_sem will prevent an actual deadlock occurring, however. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] I/O-check interface for driver's error handling
On Fri, 2005-03-04 at 14:54 +0100, Pavel Machek wrote: > Hi! > > > > If there's no ->error method, at leat call ->remove so one device only > > > takes itself down. > > > > > > Does this make sense? > > > > This was my thought too last time we had this discussion. A completely > > asynchronous call is probably needed in addition to Hidetoshi's proposed > > API, > > since as you point out, the driver may not be running when an error occurs > > (e.g. in the case of a DMA error or more general bus problem). The async > > Hmm, before we go async way (nasty locking, no?) could driver simply > ask "did something bad happen while I was sleeping?" at begining of each > function? > > For DMA problems, driver probably has its own, timer-based, > "something is wrong" timer, anyway, no? No, there is no nasty locking, when the callback happens, pretty much all IOs have stopped anyway due to errors, and we aren't on a critical code path. Polling for error might be possible, but async notification is the way to go because whatever does error management need to be able to separately: - notify all drivers on the affected bus segment - one the above is done, and based on system/driver capabilities (API to be defined) eventually re-enable IO access and do a new round of notifications - based on system/driver capabilities, eventually reset the slot and notify drivers to re-initialize themselves. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc3 04/08] ide: remove unused fields ide_drive_t->rq and ide_task_t->special
04_ide_remove_unused_fields.patch
Remove unused fields ide_drive_t->rq and ide_task_t->special
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
drivers/ide/ide-tape.c |1 -
include/linux/ide.h|2 --
2 files changed, 3 deletions(-)
Index: linux-taskfile-ng/drivers/ide/ide-tape.c
===
--- linux-taskfile-ng.orig/drivers/ide/ide-tape.c 2005-03-05
10:37:51.567375213 +0900
+++ linux-taskfile-ng/drivers/ide/ide-tape.c2005-03-05 10:46:59.482894810
+0900
@@ -1733,7 +1733,6 @@ static int idetape_end_request(ide_drive
}
ide_end_drive_cmd(drive, 0, 0);
// blkdev_dequeue_request(rq);
-// drive->rq = NULL;
// end_that_request_last(rq);
if (remove_stage)
Index: linux-taskfile-ng/include/linux/ide.h
===
--- linux-taskfile-ng.orig/include/linux/ide.h 2005-03-05 10:46:59.095955301
+0900
+++ linux-taskfile-ng/include/linux/ide.h 2005-03-05 10:46:59.483894654
+0900
@@ -660,7 +660,6 @@ typedef struct ide_drive_s {
request_queue_t *queue; /* request queue */
- struct request *rq;/* current request */
struct ide_drive_s *next; /* circular list of hwgroup drives */
struct ide_driver_s *driver;/* (ide_driver_t *) */
void*driver_data; /* extra driver data */
@@ -934,7 +933,6 @@ typedef struct ide_task_s {
ide_pre_handler_t *prehandler;
ide_handler_t *handler;
struct request *rq;/* copy of request */
- void*special; /* valid_t generally */
} ide_task_t;
typedef struct hwgroup_s {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc3 00/08] ide: taskfile cleanup
Oh, all the patches are against ide-dev-t + 9 recent patches + ide_dma_intr fix. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc3 01/08] ide: add individual ATA_TFLAG_{OUT|IN}_* flags
01_ide_TFLAG_OUT_IN.patch
This patch replaces ide_task_t->tf_{out|in}_flags handling
with newly defined individual ATA_TFLAG_{OUT|IN}_* flags and
helper functions ide_{load|read}_taskfile(). To ease
transition of the IDE code, temporary flags
ATA_TFLAG_IDE_FLAGGED and ATA_TFLAG_IDE_LBA48 are defined.
This patch is tit-for-tat and shouldn't change any behavior.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
drivers/ide/ide-disk.c |4
drivers/ide/ide-io.c | 35 +--
drivers/ide/ide-taskfile.c | 220 +++--
include/linux/ata.h| 66 -
include/linux/ide.h| 10 +-
5 files changed, 213 insertions(+), 122 deletions(-)
Index: linux-taskfile-ng/drivers/ide/ide-disk.c
===
--- linux-taskfile-ng.orig/drivers/ide/ide-disk.c 2005-03-05
10:37:51.738348597 +0900
+++ linux-taskfile-ng/drivers/ide/ide-disk.c2005-03-05 10:46:58.305078940
+0900
@@ -337,7 +337,7 @@ static u64 idedisk_read_native_max_addre
tf->device = 0x40;
if (lba48) {
tf->command = WIN_READ_NATIVE_MAX_EXT;
- tf->flags |= ATA_TFLAG_LBA48;
+ tf->flags |= ATA_TFLAG_IDE_LBA48;
} else
tf->command = WIN_READ_NATIVE_MAX;
@@ -379,7 +379,7 @@ static u64 idedisk_set_max_address(ide_d
tf->device = 0x40;
tf->command = WIN_SET_MAX_EXT;
- tf->flags |= ATA_TFLAG_LBA48;
+ tf->flags |= ATA_TFLAG_IDE_LBA48;
} else {
tf->device = ((addr_req >> 24) & 0xf) | 0x40;
tf->command = WIN_SET_MAX;
Index: linux-taskfile-ng/drivers/ide/ide-io.c
===
--- linux-taskfile-ng.orig/drivers/ide/ide-io.c 2005-03-05 10:37:51.738348597
+0900
+++ linux-taskfile-ng/drivers/ide/ide-io.c 2005-03-05 10:46:58.307078627
+0900
@@ -64,7 +64,7 @@ void ide_task_init_flush(ide_drive_t *dr
if (ide_id_has_flush_cache_ext(drive->id) &&
(drive->capacity64 >= (1UL << 28))) {
tf->command = WIN_FLUSH_CACHE_EXT;
- tf->flags |= ATA_TFLAG_LBA48;
+ tf->flags |= ATA_TFLAG_IDE_LBA48;
} else
tf->command = WIN_FLUSH_CACHE;
@@ -322,7 +322,7 @@ u64 ide_tf_get_address(ide_drive_t *driv
{
u32 high, low;
- if (tf->flags & ATA_TFLAG_LBA48) {
+ if (tf->flags & ATA_TFLAG_IDE_LBA48) {
high = (tf->hob_lbah << 16) | (tf->hob_lbam << 8) |
tf->hob_lbal;
low = (tf->lbah << 16) | (tf->lbam << 8) | tf->lbal;
} else {
@@ -458,31 +458,10 @@ void ide_end_drive_cmd (ide_drive_t *dri
if (args) {
struct ata_taskfile *tf = >tf;
-
- if (args->tf_in_flags.b.data)
- args->data = hwif->INW(IDE_DATA_REG);
-
- tf->feature = err;
-
- /* be sure we're looking at the low order bits */
- hwif->OUTB(drive->ctl & ~0x80, IDE_CONTROL_REG);
-
- tf->nsect = hwif->INB(IDE_NSECTOR_REG);
- tf->lbal= hwif->INB(IDE_SECTOR_REG);
- tf->lbam= hwif->INB(IDE_LCYL_REG);
- tf->lbah= hwif->INB(IDE_HCYL_REG);
- tf->device = hwif->INB(IDE_SELECT_REG);
- tf->command = stat;
-
- if (tf->flags & ATA_TFLAG_LBA48) {
- hwif->OUTB(drive->ctl|0x80, IDE_CONTROL_REG);
-
- tf->hob_feature = hwif->INB(IDE_FEATURE_REG);
- tf->hob_nsect = hwif->INB(IDE_NSECTOR_REG);
- tf->hob_lbal= hwif->INB(IDE_SECTOR_REG);
- tf->hob_lbam= hwif->INB(IDE_LCYL_REG);
- tf->hob_lbah= hwif->INB(IDE_HCYL_REG);
- }
+ tf->flags |= ATA_TFLAG_IN_ADDR | ATA_TFLAG_IN_DEVICE;
+ if (tf->flags & ATA_TFLAG_IDE_LBA48)
+ tf->flags |= ATA_TFLAG_IN_LBA48;
+ ide_read_taskfile(drive, args, stat, err);
}
} else if (blk_pm_request(rq)) {
#ifdef DEBUG_PM
@@ -935,7 +914,7 @@ static ide_startstop_t execute_drive_cmd
break;
}
- if (args->tf_out_flags.all != 0)
+ if (args->tf.flags & ATA_TFLAG_IDE_FLAGGED)
return flagged_taskfile(drive, args);
return do_rw_taskfile(drive, args);
} else if (rq->flags & REQ_DRIVE_CMD) {
Index: linux-taskfile-ng/drivers/ide/ide-taskfile.c
Re: Something is broken with SATA RAID ?
"J.A. Magallon" <[EMAIL PROTECTED]> wrote: > > One piece at last... > I have tried > - 2.6.11 > - 2.6.11 + libata-dev1 + netdev1 + shrinkers-at-tail + 1Gb-lowmem > > Bot work fine and survived several gigas dumped both through smb and afp. > Happy man ;). > > If there was something strange, it must be in -mm. rc5-mm1 did not work, > but plain 2.6.11 works. I will try 2.6.11-mm1 on monday... Please enable NMI watchdog, CONFIG_DETECT_SOFTLOCKUP and try sysrq-T and sysrq-P. See if we can somehow get a trace. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: slab corruption in skb allocs
Matt Mackall wrote: Which card/driver is this? Is this the same card that's showing ssh troubles? My theory about your ssh trouble only applies to cards with checksum offload. i got the same on all three machines i was testing with, with both the e100 and the eepro100 driver. one of those three machines was the one with the ssh troubles, its card is identified as "Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08)", pci id 8086:1229. plus, i couldn't reproduce those problems on a machine with e1000, which does support all kinds of checksum offloading. (there might still be something fishy with the e1000 as well, as i'm not entirely trusting the errors from the slab checkers alone. especially since i don't see those messages when i enable page alloc debugging.) another machine behaves even more strangely... its nic is identified as "Intel Corp. 82801BD PRO/100 VE (LOM) Ethernet Controller (rev 81)", pci id 8086:1039, also apparently not supporting hardware checksums. it does immediately produce the slab debug errors when i bombard it with udp packets while having disk access w/o dma, but remains silent when doing the same with a tcp transfer instead of udp packets. neither ssh traffic nor /dev/zero piped through netcat (no matter in which direction) makes it catch any errors. i only got a _single_ message from the slab debugger when sending /dev/zero through netcat in _both_ directions at the same time (in and out). however, i do get pages and pages of those messages when sending a simple stream of udp packets to the box... again, this is all with the e100 driver, i couldn't produce any similar results with the eepro100 or the e1000 driver yet, but apparently this doesn't necessarily mean that there isn't something wrong anyway... cheers richard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11.1
Greg KH wrote: On Fri, Mar 04, 2005 at 02:36:14PM -0800, Andrew Morton wrote: But we end up with a cset in the permanent kernel history which simply should not have been there. Is this really a big deal? If you are pushing linux-release to Linus/Andrew rapidly, quick fixes will land in linux-2.6 rapidly, and more invasive stuff will land only in linux-2.6 when the invasive stuff is ready to go. It even takes the pressure off pushing invasive stuff ASAP. Have you pushed linux-2.6.11.1 upstream yet? :) Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
