[PATCH] MAINTAINER change for Connect Tech Inc
From: Stuart MacDonald <[EMAIL PROTECTED]> I am no longer with CTI. The Support Department will handle all inquiries regarding the WH. Signed-off-by: Stuart MacDonald <[EMAIL PROTECTED]> --- Applies to 2.6.21. I'm also not subscribed to the list anymore so comments must be replied to me directly, and by 5:00p today. ..Stu --- linux-2.6.21/MAINTAINERS2007-04-25 23:08:32.0 -0400 +++ linux-2.6.21-new/MAINTAINERS2007-05-04 15:30:39.0 -0400 @@ -3566,8 +3566,8 @@ W:http://www.kroah.com/linux/ S: Maintained USB SERIAL WHITEHEAT DRIVER -P: Stuart MacDonald -M: [EMAIL PROTECTED] +P: Support Department +M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] L: [EMAIL PROTECTED] W: http://www.connecttech.com --- linux-2.6.21/Documentation/usb/usb-serial.txt 2007-04-25 23:08:32.0 -0400 +++ linux-2.6.21-new/Documentation/usb/usb-serial.txt 2007-05-04 15:33:56.0 -0400 @@ -42,7 +42,7 @@ ConnectTech WhiteHEAT 4 port converter http://www.connecttech.com For any questions or problems with this driver, please contact - Stuart MacDonald at [EMAIL PROTECTED] + Connect Tech's Support Department at [EMAIL PROTECTED] HandSpring Visor, Palm USB, and Clié USB driver - 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] MAINTAINER change for Connect Tech Inc
From: Stuart MacDonald [EMAIL PROTECTED] I am no longer with CTI. The Support Department will handle all inquiries regarding the WH. Signed-off-by: Stuart MacDonald [EMAIL PROTECTED] --- Applies to 2.6.21. I'm also not subscribed to the list anymore so comments must be replied to me directly, and by 5:00p today. ..Stu --- linux-2.6.21/MAINTAINERS2007-04-25 23:08:32.0 -0400 +++ linux-2.6.21-new/MAINTAINERS2007-05-04 15:30:39.0 -0400 @@ -3566,8 +3566,8 @@ W:http://www.kroah.com/linux/ S: Maintained USB SERIAL WHITEHEAT DRIVER -P: Stuart MacDonald -M: [EMAIL PROTECTED] +P: Support Department +M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] L: [EMAIL PROTECTED] W: http://www.connecttech.com --- linux-2.6.21/Documentation/usb/usb-serial.txt 2007-04-25 23:08:32.0 -0400 +++ linux-2.6.21-new/Documentation/usb/usb-serial.txt 2007-05-04 15:33:56.0 -0400 @@ -42,7 +42,7 @@ ConnectTech WhiteHEAT 4 port converter http://www.connecttech.com For any questions or problems with this driver, please contact - Stuart MacDonald at [EMAIL PROTECTED] + Connect Tech's Support Department at [EMAIL PROTECTED] HandSpring Visor, Palm USB, and Clié USB driver - 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: condingstyle, was Re: utrace comments
From: On Behalf Of Satyam Sharma
> readable and obvious at first glance itself. For example, consider:
^^^
>
> if (veryverylengthycondition1 &&
> smallcond2 &&
> (conditionnumber3a ||
> condition3b)) {
> ...
> }
>
> versus
Whoops! You've got an unterminated if there, let me fix it up...
> if (veryverylengthycondition1) {
> && smallcond2
> && (conditionnumber3a
> || condition3b)) {
> ...
> }>
From: On Behalf Of Scott Preece
> I still find the leading-operator style much more readable. The most
> important thing in reading a long, complex conditional is
> understanding the structure of the operators, not the operands.
Since there's a mix of pre-, post- and infix, the structure of the
operators _depends on_ the operands.
> However, there's a lot of difference of opinion on this (perhaps
> rooted in differences in cognition and reading behavior). For me it's
> not even close - expressions broken so the operators are at the head
> of the line snap into focus and those with operators at the ends of
> the lines look like undifferentiated goo. Since some of the style
I'm exactly opposite; the "uncorrected" line above is a typo because
there's no continuation item at the end of the line. I don't even see
the following lines because they are, by definition, not part of the
code I'm looking at. Leaving the operators at the end of the line I
easily see that it's a binary operator, and there's no second operand
so the next line must contain it, parse the next line as well.
Hm. I didn't realise this but the unspoken underlying factor for me is
the "one instruction per line" style. If you must break over multiple
lines, there must be a continuation item to indicate that. This is how
I detect missing semicolons.
..Stu
-
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: condingstyle, was Re: utrace comments
From: On Behalf Of Satyam Sharma
readable and obvious at first glance itself. For example, consider:
^^^
if (veryverylengthycondition1
smallcond2
(conditionnumber3a ||
condition3b)) {
...
}
versus
Whoops! You've got an unterminated if there, let me fix it up...
if (veryverylengthycondition1) {
smallcond2
(conditionnumber3a
|| condition3b)) {
...
}
From: On Behalf Of Scott Preece
I still find the leading-operator style much more readable. The most
important thing in reading a long, complex conditional is
understanding the structure of the operators, not the operands.
Since there's a mix of pre-, post- and infix, the structure of the
operators _depends on_ the operands.
However, there's a lot of difference of opinion on this (perhaps
rooted in differences in cognition and reading behavior). For me it's
not even close - expressions broken so the operators are at the head
of the line snap into focus and those with operators at the ends of
the lines look like undifferentiated goo. Since some of the style
I'm exactly opposite; the uncorrected line above is a typo because
there's no continuation item at the end of the line. I don't even see
the following lines because they are, by definition, not part of the
code I'm looking at. Leaving the operators at the end of the line I
easily see that it's a binary operator, and there's no second operand
so the next line must contain it, parse the next line as well.
Hm. I didn't realise this but the unspoken underlying factor for me is
the one instruction per line style. If you must break over multiple
lines, there must be a continuation item to indicate that. This is how
I detect missing semicolons.
..Stu
-
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/
Support for Zilog or Infineon hardware?
We have been investigating Linux support for the following chips:
Zilog Z16C30 (also known as the "USC" or just 16C30)
Zilog Z16C32 (also known as the "IUSC" or just 16C32)
http://www.zilog.com/products/family.asp?fam=200
Infineon"SEROCCO" family
SAB/SAF-20532 ("Serial Optimized Communications Controller")
SAB/SAF-20542 ("Serial Optimized Communications Controller with
DMA")
http://www.infineon.com/cgi-bin/ifx/portal/ep/channelView.do?channelId=-65034=%2Fep%2Fchannel%2FleafNote.jsp=
17099
I grepped 6.20 and 4.34 extensively, and found
drivers/char/synclink*.c which appear to use the 16C32. Google turned
up http://www.evolware.org/chri/serocco/index.html for the Infineon
chips, but it's an out-of-tree driver.
Is anyone aware of any other Linux drivers for those chips?
..Stu
-
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/
Support for Zilog or Infineon hardware?
We have been investigating Linux support for the following chips: Zilog Z16C30 (also known as the USC or just 16C30) Zilog Z16C32 (also known as the IUSC or just 16C32) http://www.zilog.com/products/family.asp?fam=200 InfineonSEROCCO family SAB/SAF-20532 (Serial Optimized Communications Controller) SAB/SAF-20542 (Serial Optimized Communications Controller with DMA) http://www.infineon.com/cgi-bin/ifx/portal/ep/channelView.do?channelId=-65034channelPage=%2Fep%2Fchannel%2FleafNote.jsppageTypeId= 17099 I grepped 6.20 and 4.34 extensively, and found drivers/char/synclink*.c which appear to use the 16C32. Google turned up http://www.evolware.org/chri/serocco/index.html for the Infineon chips, but it's an out-of-tree driver. Is anyone aware of any other Linux drivers for those chips? ..Stu - 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: Alternative to 'git bisect visualize'?
From: Randy Dunlap [mailto:[EMAIL PROTECTED] > On Tue, 10 Apr 2007 15:45:33 -0400 Stuart MacDonald wrote: > > Where would be the appropriate place to submit this as a feature > > request, to complement "git bisect visualize"; git, LKML or > somewhere > > else? I'm picturing an ncurses/menuconfig-style app. > > see http://git.or.cz/, this section: Community and Development Thanks. ..Stu - 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: Alternative to 'git bisect visualize'?
From: Paolo Ornati [mailto:[EMAIL PROTECTED] > I think this should work: > > 1) look at "git-bisect log" and take the last good/bad pair > > 2) "cat .git/refs/heads/bisect" to see where you are now > > 3) git-log --pretty=oneline GOOD..BAD > > 4) search for the current commit (found in #2) with "/CURRENT_COMMIT", > now move around and choose another commit to test > > 5) git-reset --hard COMMIT_TO_TEST That is exactly what I needed, many many thanks. I have moved off the broken area of commits and am back into bisecting. Where would be the appropriate place to submit this as a feature request, to complement "git bisect visualize"; git, LKML or somewhere else? I'm picturing an ncurses/menuconfig-style app. ..Stu - 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: Alternative to 'git bisect visualize'?
From: Paolo Ornati [mailto:[EMAIL PROTECTED] I think this should work: 1) look at git-bisect log and take the last good/bad pair 2) cat .git/refs/heads/bisect to see where you are now 3) git-log --pretty=oneline GOOD..BAD 4) search for the current commit (found in #2) with /CURRENT_COMMIT, now move around and choose another commit to test 5) git-reset --hard COMMIT_TO_TEST That is exactly what I needed, many many thanks. I have moved off the broken area of commits and am back into bisecting. Where would be the appropriate place to submit this as a feature request, to complement git bisect visualize; git, LKML or somewhere else? I'm picturing an ncurses/menuconfig-style app. ..Stu - 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: Alternative to 'git bisect visualize'?
From: Randy Dunlap [mailto:[EMAIL PROTECTED] On Tue, 10 Apr 2007 15:45:33 -0400 Stuart MacDonald wrote: Where would be the appropriate place to submit this as a feature request, to complement git bisect visualize; git, LKML or somewhere else? I'm picturing an ncurses/menuconfig-style app. see http://git.or.cz/, this section: Community and Development Thanks. ..Stu - 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/
Alternative to 'git bisect visualize'?
The git mailing list seems to be git-dev, and I can't find a git-users list anywhere. If there's somewhere better to ask this, please point me in the right direction. I've been learning git over the last few days. Specifically, I'm trying out git bisect to locate a change between 2.6.17 and 2.6.18 that broke something. I've reached a point where the kernel I build does not boot. Linus says http://www.kernel.org/pub/software/scm/git/docs/howto/isolate-bugs-with-bisect.txt "you should try to find another commit close-by". Other docs I've read imply this is done with git bisect visualize. My problem is that I don't have wish/tk installed. Is there a text-based alternative to visualize that I can use? Or is there a different method to locate a nearby commit? The answer may involve something as simple as looking at some git state; I am a git newbie, and reading the docs hasn't helped any, so I won't be surprised to find out I'm overlooking something really obvious. Thanks in advance for any and all help, ..Stu - 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/
Alternative to 'git bisect visualize'?
The git mailing list seems to be git-dev, and I can't find a git-users list anywhere. If there's somewhere better to ask this, please point me in the right direction. I've been learning git over the last few days. Specifically, I'm trying out git bisect to locate a change between 2.6.17 and 2.6.18 that broke something. I've reached a point where the kernel I build does not boot. Linus says http://www.kernel.org/pub/software/scm/git/docs/howto/isolate-bugs-with-bisect.txt you should try to find another commit close-by. Other docs I've read imply this is done with git bisect visualize. My problem is that I don't have wish/tk installed. Is there a text-based alternative to visualize that I can use? Or is there a different method to locate a nearby commit? The answer may involve something as simple as looking at some git state; I am a git newbie, and reading the docs hasn't helped any, so I won't be surprised to find out I'm overlooking something really obvious. Thanks in advance for any and all help, ..Stu - 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: Silent corruption on AMD64
From: On Behalf Of Aaron Lehmann > I've been able to narrow it down to the Realtek Ethernet card. I can't > reproduce the problem using onboard Ethernet, whereas the Realtek card > causes trouble in any slot. However, I still don't know whether it's a > hardware or software issue, or whether it's caused directly or > indirectly by the Realtek card. I had a similar issue recently: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=223216 I recommend trying Doug Ledford's memtest script: http://people.redhat.com/dledford/memtest.html It helped me prove the issue was the hardware and not something else. ..Stu - 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: Silent corruption on AMD64
From: On Behalf Of Aaron Lehmann I've been able to narrow it down to the Realtek Ethernet card. I can't reproduce the problem using onboard Ethernet, whereas the Realtek card causes trouble in any slot. However, I still don't know whether it's a hardware or software issue, or whether it's caused directly or indirectly by the Realtek card. I had a similar issue recently: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=223216 I recommend trying Doug Ledford's memtest script: http://people.redhat.com/dledford/memtest.html It helped me prove the issue was the hardware and not something else. ..Stu - 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: question on tty open and close
From: Oliver Neukum [mailto:[EMAIL PROTECTED] > Am Mittwoch, 28. März 2007 15:10 schrieb Stuart MacDonald: > > > We find that a failure in open() leads to release_dev() > being called. > > > release_dev() calls close(): > > > > > > if (tty->driver->close) > > > tty->driver->close(tty, filp); > > > > > > So we have a file that's closed although open() never succeeded? > > > > That's correct! It's been a pain in my butt for years. > > How did you deal with that proctological issue? Just make sure the close() handles the situation properly. It makes reference counting... fun. The serial driver has always handled it like this. ..Stu - 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: question on tty open and close
From: [EMAIL PROTECTED] > in tty_io.c::tty_open(): [snip] > We find that a failure in open() leads to release_dev() being called. > release_dev() calls close(): > > if (tty->driver->close) > tty->driver->close(tty, filp); > > So we have a file that's closed although open() never succeeded? That's correct! It's been a pain in my butt for years. > What's the reason for that? No idea. Would *love* to hear an explanation. ..Stu - 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: question on tty open and close
From: [EMAIL PROTECTED] in tty_io.c::tty_open(): [snip] We find that a failure in open() leads to release_dev() being called. release_dev() calls close(): if (tty-driver-close) tty-driver-close(tty, filp); So we have a file that's closed although open() never succeeded? That's correct! It's been a pain in my butt for years. What's the reason for that? No idea. Would *love* to hear an explanation. ..Stu - 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: question on tty open and close
From: Oliver Neukum [mailto:[EMAIL PROTECTED] Am Mittwoch, 28. März 2007 15:10 schrieb Stuart MacDonald: We find that a failure in open() leads to release_dev() being called. release_dev() calls close(): if (tty-driver-close) tty-driver-close(tty, filp); So we have a file that's closed although open() never succeeded? That's correct! It's been a pain in my butt for years. How did you deal with that proctological issue? Just make sure the close() handles the situation properly. It makes reference counting... fun. The serial driver has always handled it like this. ..Stu - 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] usb/serial/whiteheat: Convert to generic boolean
From: Richard Knutsson [mailto:[EMAIL PROTECTED]
Okay by me. Thanks Richard.
Signed-off-by: Stuart MacDonald <[EMAIL PROTECTED]>
..Stu
> Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
> ---
> Compile-tested with "allyes", "allmod" & "allno" on i386
>
>
> diff --git a/drivers/usb/serial/whiteheat.c
> b/drivers/usb/serial/whiteheat.c
> index bf16e9e..27c5f8f 100644
> --- a/drivers/usb/serial/whiteheat.c
> +++ b/drivers/usb/serial/whiteheat.c
> @@ -1109,7 +1109,7 @@ static int firm_send_command (struct
> usb_serial_port *port, __u8 command, __u8 *
> command_port = port->serial->port[COMMAND_PORT];
> command_info = usb_get_serial_port_data(command_port);
> spin_lock_irqsave(_info->lock, flags);
> - command_info->command_finished = FALSE;
> + command_info->command_finished = false;
>
> transfer_buffer = (__u8
> *)command_port->write_urb->transfer_buffer;
> transfer_buffer[0] = command;
> @@ -1124,12 +1124,12 @@ static int firm_send_command (struct
> usb_serial_port *port, __u8 command, __u8 *
> spin_unlock_irqrestore(_info->lock, flags);
>
> /* wait for the command to complete */
> - wait_event_interruptible_timeout(command_info->wait_command,
> - (command_info->command_finished != FALSE),
> COMMAND_TIMEOUT);
> + wait_event_interruptible_timeout(command_info->wait_command,
> + (bool)command_info->command_finished, COMMAND_TIMEOUT);
>
> spin_lock_irqsave(_info->lock, flags);
>
> - if (command_info->command_finished == FALSE) {
> + if (command_info->command_finished == false) {
> dbg("%s - command timed out.", __FUNCTION__);
> retval = -ETIMEDOUT;
> goto exit;
> diff --git a/drivers/usb/serial/whiteheat.h
> b/drivers/usb/serial/whiteheat.h
> index d714eff..f160797 100644
> --- a/drivers/usb/serial/whiteheat.h
> +++ b/drivers/usb/serial/whiteheat.h
> @@ -20,10 +20,6 @@
> #define __LINUX_USB_SERIAL_WHITEHEAT_H
>
>
> -#define FALSE0
> -#define TRUE 1
> -
> -
> /* WhiteHEAT commands */
> #define WHITEHEAT_OPEN 1 /* open
> the port */
> #define WHITEHEAT_CLOSE 2 /*
> close the port */
>
-
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] usb/serial/whiteheat: Convert to generic boolean
From: Richard Knutsson [mailto:[EMAIL PROTECTED]
Okay by me. Thanks Richard.
Signed-off-by: Stuart MacDonald [EMAIL PROTECTED]
..Stu
Signed-off-by: Richard Knutsson [EMAIL PROTECTED]
---
Compile-tested with allyes, allmod allno on i386
diff --git a/drivers/usb/serial/whiteheat.c
b/drivers/usb/serial/whiteheat.c
index bf16e9e..27c5f8f 100644
--- a/drivers/usb/serial/whiteheat.c
+++ b/drivers/usb/serial/whiteheat.c
@@ -1109,7 +1109,7 @@ static int firm_send_command (struct
usb_serial_port *port, __u8 command, __u8 *
command_port = port-serial-port[COMMAND_PORT];
command_info = usb_get_serial_port_data(command_port);
spin_lock_irqsave(command_info-lock, flags);
- command_info-command_finished = FALSE;
+ command_info-command_finished = false;
transfer_buffer = (__u8
*)command_port-write_urb-transfer_buffer;
transfer_buffer[0] = command;
@@ -1124,12 +1124,12 @@ static int firm_send_command (struct
usb_serial_port *port, __u8 command, __u8 *
spin_unlock_irqrestore(command_info-lock, flags);
/* wait for the command to complete */
- wait_event_interruptible_timeout(command_info-wait_command,
- (command_info-command_finished != FALSE),
COMMAND_TIMEOUT);
+ wait_event_interruptible_timeout(command_info-wait_command,
+ (bool)command_info-command_finished, COMMAND_TIMEOUT);
spin_lock_irqsave(command_info-lock, flags);
- if (command_info-command_finished == FALSE) {
+ if (command_info-command_finished == false) {
dbg(%s - command timed out., __FUNCTION__);
retval = -ETIMEDOUT;
goto exit;
diff --git a/drivers/usb/serial/whiteheat.h
b/drivers/usb/serial/whiteheat.h
index d714eff..f160797 100644
--- a/drivers/usb/serial/whiteheat.h
+++ b/drivers/usb/serial/whiteheat.h
@@ -20,10 +20,6 @@
#define __LINUX_USB_SERIAL_WHITEHEAT_H
-#define FALSE0
-#define TRUE 1
-
-
/* WhiteHEAT commands */
#define WHITEHEAT_OPEN 1 /* open
the port */
#define WHITEHEAT_CLOSE 2 /*
close the port */
-
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: module builds need improvement / top Makefile not good enough
From: On Behalf Of FN > Currently I face the following situation -- I try to build 2 drivers > from the same Makefile > --- > CWD := $(shell pwd) > obj-m := driver1.o driver2.o > driver1-y := d1/d2/d3/f1.o d1/d2/f2.o > driver2-y := d1/d5/file1.o d1/d6/file2.o CFLAGS_f1.o := -DMASK=0x123 CFLAGS_file1.o := -DMASK=0x123 CFLAGS_f2.o := -DMASK=0x456 CFLAGS_file2.o := -DMASK=0x456 > -- > There are 2 problems here > 1) kbuild is forcing me to declare EXTRA_CFLAGS in global scope and >I can't build my drivers properly because the MASKs are > incompatible. Fixed your makefile for you. See Documentation/kbuild/modules. ..Stu - 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: module builds need improvement / top Makefile not good enough
From: On Behalf Of FN Currently I face the following situation -- I try to build 2 drivers from the same Makefile --- CWD := $(shell pwd) obj-m := driver1.o driver2.o driver1-y := d1/d2/d3/f1.o d1/d2/f2.o driver2-y := d1/d5/file1.o d1/d6/file2.o CFLAGS_f1.o := -DMASK=0x123 CFLAGS_file1.o := -DMASK=0x123 CFLAGS_f2.o := -DMASK=0x456 CFLAGS_file2.o := -DMASK=0x456 -- There are 2 problems here 1) kbuild is forcing me to declare EXTRA_CFLAGS in global scope and I can't build my drivers properly because the MASKs are incompatible. Fixed your makefile for you. See Documentation/kbuild/modules. ..Stu - 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: questions about 8250 uart support for adhoc boards
From: Russell King [mailto:[EMAIL PROTECTED] > After experimenting here, it turns out the reason is you're trying to > configure a port with a zero base baud. Unfortunately, it starts off > as zero. That explains why adding the fourport module fixed Rob's issue, as the fourport code sets a uartclk value for its ports. > However, when you try to change a port without specifying the > base baud, > it is possible for the port to become "usable" and unless we enforce > the "must not have zero base baud" rule we have the > possibility to oops > the kernel via a divide by zero. > > So, the answer is to specify the base baud when using setserial to > configure new ports. Would it be more intuitive to give ports the default uartclk of 1843200 at init time? That would avoid this issue, but would make the baud rates come out wrong on hardware with a non-standard clock, if a base baud wasn't specified. From: Rob Prowel [mailto:[EMAIL PROTECTED] > your website address didn't work when I tried it... The website may have been down on the weekend for maintenance. Please try again. ..Stu -- We make multiport serial products. http://www.connecttech.com/ (800) 426-8979 - 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: questions about 8250 uart support for adhoc boards
From: Russell King [mailto:[EMAIL PROTECTED] After experimenting here, it turns out the reason is you're trying to configure a port with a zero base baud. Unfortunately, it starts off as zero. That explains why adding the fourport module fixed Rob's issue, as the fourport code sets a uartclk value for its ports. However, when you try to change a port without specifying the base baud, it is possible for the port to become usable and unless we enforce the must not have zero base baud rule we have the possibility to oops the kernel via a divide by zero. So, the answer is to specify the base baud when using setserial to configure new ports. Would it be more intuitive to give ports the default uartclk of 1843200 at init time? That would avoid this issue, but would make the baud rates come out wrong on hardware with a non-standard clock, if a base baud wasn't specified. From: Rob Prowel [mailto:[EMAIL PROTECTED] your website address didn't work when I tried it... The website may have been down on the weekend for maintenance. Please try again. ..Stu -- We make multiport serial products. http://www.connecttech.com/ (800) 426-8979 - 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: questions about 8250 uart support for adhoc boards
From: On Behalf Of Rob Prowel > Russell King wrote: > > You don't even need to do that. Just configure SERIAL_8250_NR_UARTS > > and SERIAL_8250_RUNTIME_UARTS appropriately for your > system. There's > > absolutely no need to build any of the additional modules. > > > Unfortunately what I'm seeing in 2.6.20.1 seems to differ > from this. If PC104 is really an ISA bus. The ISA ports are stored in a table in the 8250 driver (instead of allocated dynamically like PCI ports); the config option _NR_UARTS just tells the driver how large to make the table. > I use the options below: > > CONFIG_SERIAL_8250=y > CONFIG_SERIAL_8250_CONSOLE=y > CONFIG_SERIAL_8250_PCI=y > CONFIG_SERIAL_8250_NR_UARTS=32 This makes the internal table be 32 ports big. The first four ports end up configured for legacy/standard com ports, the rest are unconfigured. You should be able to see them as unknowns with setserial. > CONFIG_SERIAL_8250_RUNTIME_UARTS=16 > CONFIG_SERIAL_8250_EXTENDED=y > CONFIG_SERIAL_8250_MANY_PORTS=y > # CONFIG_SERIAL_8250_FOURPORT is not set All _FOURPORT does is specifically config ports 4-7 in the table to have specific address/irqs for the FourPort board. What you do with setserial is then change that config info to match your board. You shouldn't need to do this, and I quickly reviewed 2.6.20.1 and it looks like you don't. As long as _NR_UARTS is big enough, thus making the internal table big enough, you should be able to configure, with setserial, any of the ports in the table, including the first four. > Then I can only access ttyS0 through ttyS3 sith setserial. > Only after I add > CONFIG_SERIAL_8250_FOURPORT=y am I actually able to do > anything with the > additional ports. I would otherwise get the evil setserial: invalid > parameter error. Very odd. You get this error when doing "setserial /dev/ttySxx", no configuration? If so, that would imply that the table wasn't made big enough, and the unconfigured ports haven't been registered with the serial core. > OK. Fair enough. My question then becomes, how does the driver deal > with this now? scan all applicable uarts when any relevant > interrupt is > detected (as identified in setserial)? With our boards, the multiport is just a status register; it shows which port has produced the interrupt, so the driver doesn't have to loop through all the ports on the board looking for the correct one. It doesn't actually enable/disable the sharing of the interrupt. The setting of "irq 12" on multiple ports (from your original post) is what enables the sharing, from the driver-side view. Maybe your hardware is unusual and requires this ISR port to be set properly to enable sharing; more likely is that the board itself has one or more jumpers to set which interrupt it's using, and that's what enables the sharing from the hardware-side view. If I get some time tomorrow, I'll set up 2.6.20.1 and see what the current options are doing. If you can't get your board working, we have similar boards that do. ..Stu -- We make multiport serial products. http://www.connecttech.com/ (800) 426-8979 - 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: questions about 8250 uart support for adhoc boards
From: On Behalf Of Rob Prowel Russell King wrote: You don't even need to do that. Just configure SERIAL_8250_NR_UARTS and SERIAL_8250_RUNTIME_UARTS appropriately for your system. There's absolutely no need to build any of the additional modules. Unfortunately what I'm seeing in 2.6.20.1 seems to differ from this. If PC104 is really an ISA bus. The ISA ports are stored in a table in the 8250 driver (instead of allocated dynamically like PCI ports); the config option _NR_UARTS just tells the driver how large to make the table. I use the options below: CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_PCI=y CONFIG_SERIAL_8250_NR_UARTS=32 This makes the internal table be 32 ports big. The first four ports end up configured for legacy/standard com ports, the rest are unconfigured. You should be able to see them as unknowns with setserial. CONFIG_SERIAL_8250_RUNTIME_UARTS=16 CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_MANY_PORTS=y # CONFIG_SERIAL_8250_FOURPORT is not set All _FOURPORT does is specifically config ports 4-7 in the table to have specific address/irqs for the FourPort board. What you do with setserial is then change that config info to match your board. You shouldn't need to do this, and I quickly reviewed 2.6.20.1 and it looks like you don't. As long as _NR_UARTS is big enough, thus making the internal table big enough, you should be able to configure, with setserial, any of the ports in the table, including the first four. Then I can only access ttyS0 through ttyS3 sith setserial. Only after I add CONFIG_SERIAL_8250_FOURPORT=y am I actually able to do anything with the additional ports. I would otherwise get the evil setserial: invalid parameter error. Very odd. You get this error when doing setserial /dev/ttySxx, no configuration? If so, that would imply that the table wasn't made big enough, and the unconfigured ports haven't been registered with the serial core. OK. Fair enough. My question then becomes, how does the driver deal with this now? scan all applicable uarts when any relevant interrupt is detected (as identified in setserial)? With our boards, the multiport is just a status register; it shows which port has produced the interrupt, so the driver doesn't have to loop through all the ports on the board looking for the correct one. It doesn't actually enable/disable the sharing of the interrupt. The setting of irq 12 on multiple ports (from your original post) is what enables the sharing, from the driver-side view. Maybe your hardware is unusual and requires this ISR port to be set properly to enable sharing; more likely is that the board itself has one or more jumpers to set which interrupt it's using, and that's what enables the sharing from the hardware-side view. If I get some time tomorrow, I'll set up 2.6.20.1 and see what the current options are doing. If you can't get your board working, we have similar boards that do. ..Stu -- We make multiport serial products. http://www.connecttech.com/ (800) 426-8979 - 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: GPL vs non-GPL device drivers
From: On Behalf Of v j > On 2/14/07, Randy Dunlap <[EMAIL PROTECTED]> wrote: > > We seem to have different definitions of open and closed. > > Open = 3rd party Linux drivers can be loaded. Closed = No third party > Linux drivers can be loaded. That is BSD-openness; the freedom to do anything with the code you receive, including making it so that others who receive modified code from you *don't* have the same freedom. Linux is GPLed, and thus uses GPL-openness: Open = All source code is available to all, so that the code may survive and freedoms be preserved. Closed = Non-available source code. This ensures that others who receive modified code from you also receive the same freedoms you received. From: On Behalf Of v j > Sent: February 15, 2007 12:39 AM > No its not. It wasn't common knowledge 3 years ago when we chose Linux > as an embedded platform. If it indeed is common knowledge that > loadable modules in Linux have to be open-source then it is very > probable that we wouldn't have chosen Linux as the platform of choice. Counter-example: we've been using uClinux in an embedded system since 2002, over 4 years. It was common knowledge at that time that many people, including some lawyers, considered drivers to be a derived work of the kernel and thus the GPL would apply to them. That's how I found out about it. Linus does allow for one exception; drivers written for other OSes that happen to compile for Linux as well. I believe this is the POSIX exception mentioned elsethread. However, from your description of requiring GPL-only symbols, I'm pretty sure your driver is a derived work. Since you're distributing it (inside your device), the code must be made available, under the GPL. You also asserted that the code is only useful to your competitors. That simply is not true. No company suppports a product forever, even if they believe they will. Once that support is gone, the only way to fix bugs or improve the product is to **have the code in hand**. THAT is what the GPL-openness is all about. THAT is when the code is useful to the open source community at large. Since that need is inevitable, the code must be provided up-front, when distribution starts. ..Stu - 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: GPL vs non-GPL device drivers
From: On Behalf Of v j On 2/14/07, Randy Dunlap [EMAIL PROTECTED] wrote: We seem to have different definitions of open and closed. Open = 3rd party Linux drivers can be loaded. Closed = No third party Linux drivers can be loaded. That is BSD-openness; the freedom to do anything with the code you receive, including making it so that others who receive modified code from you *don't* have the same freedom. Linux is GPLed, and thus uses GPL-openness: Open = All source code is available to all, so that the code may survive and freedoms be preserved. Closed = Non-available source code. This ensures that others who receive modified code from you also receive the same freedoms you received. From: On Behalf Of v j Sent: February 15, 2007 12:39 AM No its not. It wasn't common knowledge 3 years ago when we chose Linux as an embedded platform. If it indeed is common knowledge that loadable modules in Linux have to be open-source then it is very probable that we wouldn't have chosen Linux as the platform of choice. Counter-example: we've been using uClinux in an embedded system since 2002, over 4 years. It was common knowledge at that time that many people, including some lawyers, considered drivers to be a derived work of the kernel and thus the GPL would apply to them. That's how I found out about it. Linus does allow for one exception; drivers written for other OSes that happen to compile for Linux as well. I believe this is the POSIX exception mentioned elsethread. However, from your description of requiring GPL-only symbols, I'm pretty sure your driver is a derived work. Since you're distributing it (inside your device), the code must be made available, under the GPL. You also asserted that the code is only useful to your competitors. That simply is not true. No company suppports a product forever, even if they believe they will. Once that support is gone, the only way to fix bugs or improve the product is to **have the code in hand**. THAT is what the GPL-openness is all about. THAT is when the code is useful to the open source community at large. Since that need is inevitable, the code must be provided up-front, when distribution starts. ..Stu - 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: Serial port blues
From: On Behalf Of Joe Barr > I'm forwarding this post by the author of a great little program for > digital amateur radio on Linux, because I'm curious whether or not the > problem he is seeing can be resolved outside the kernel. From: w1hkj [mailto:[EMAIL PROTECTED] > I am now convinced that the current serial port drivers > available to us > on the Linux platform WILL NOT support CW and/or RTTY that is > software > generated in a satisfactory manner. I don't know what FSK/CW/RTTY/BAUDOT is. > Direct access to the serial port(s) is a kernel perogative in Linux. > Only kernel level drivers are allowed such port access. Not true. > Until such time as new information becomes available I am going to > comment out all references to CW and / or FSK via RTS/DTR. I also > question how useful the FSK on TxD (UART derived) might be to > most users > since the 45.45 baudrate is not available in the serial port driver. > That function will also be commented out. You may be confusing the old-style baud rate lookup table (B9600 et al) with the actual capabilities of the serial port. The lookup table has a limited number of baud rates. You can get more rates than that using a custom divisor. Most motherboard-based serial ports are clocked at 1.8432 Mhz. The UART does 16 samples per bit time, yielding a max baud rate of 115200. 115200 / 25 yields 4608, which is a 1.4% error rate from 4545. This may or may not be acceptable. 115200 / 2535 yields 45.44, which is a 0.01% error rate, which is likely acceptable. > Sorry folks, but we win some and lose some. We make serial port boards with very flexible UARTS. 4545 exactly is achievable. 45.45 too. Linux supported. ..Stu -- We make multiport serial products. http://www.connecttech.com/ (800) 426-8979 - 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: Serial port blues
From: On Behalf Of Joe Barr I'm forwarding this post by the author of a great little program for digital amateur radio on Linux, because I'm curious whether or not the problem he is seeing can be resolved outside the kernel. From: w1hkj [mailto:[EMAIL PROTECTED] I am now convinced that the current serial port drivers available to us on the Linux platform WILL NOT support CW and/or RTTY that is software generated in a satisfactory manner. I don't know what FSK/CW/RTTY/BAUDOT is. Direct access to the serial port(s) is a kernel perogative in Linux. Only kernel level drivers are allowed such port access. Not true. Until such time as new information becomes available I am going to comment out all references to CW and / or FSK via RTS/DTR. I also question how useful the FSK on TxD (UART derived) might be to most users since the 45.45 baudrate is not available in the serial port driver. That function will also be commented out. You may be confusing the old-style baud rate lookup table (B9600 et al) with the actual capabilities of the serial port. The lookup table has a limited number of baud rates. You can get more rates than that using a custom divisor. Most motherboard-based serial ports are clocked at 1.8432 Mhz. The UART does 16 samples per bit time, yielding a max baud rate of 115200. 115200 / 25 yields 4608, which is a 1.4% error rate from 4545. This may or may not be acceptable. 115200 / 2535 yields 45.44, which is a 0.01% error rate, which is likely acceptable. Sorry folks, but we win some and lose some. We make serial port boards with very flexible UARTS. 4545 exactly is achievable. 45.45 too. Linux supported. ..Stu -- We make multiport serial products. http://www.connecttech.com/ (800) 426-8979 - 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: tty line discipline driver advice sought, to do a 1-byte header and 2-byte CRC checksum on GSM data
From: On Behalf Of Luke Kenneth Casson Leighton > Subject: Re: tty line discipline driver advice sought, to do > a 1-byte header and 2-byte CRC checksum on GSM data drivers/char/n_tty.c include/linux/tty_ldisc.h include/linux/tty_flip.h include/linux/tty.h I can't see a reason why your code shouldn't be a perfect fit as an ldisc. ..Stu - 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: tty line discipline driver advice sought, to do a 1-byte header and 2-byte CRC checksum on GSM data
From: On Behalf Of Luke Kenneth Casson Leighton Subject: Re: tty line discipline driver advice sought, to do a 1-byte header and 2-byte CRC checksum on GSM data drivers/char/n_tty.c include/linux/tty_ldisc.h include/linux/tty_flip.h include/linux/tty.h I can't see a reason why your code shouldn't be a perfect fit as an ldisc. ..Stu - 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: Need break driver<-->pci-device automatic association
From: Jacques Goldberg > To be ugly or to never be up to date, that's the question. > We did patch 8250_pci.c but there is no way to build a > stable list of > the devices to be handled that way. > We will thus spend some time on the hot unplug solution. I think what you want might be accomplished if the serial driver was compiled as a module. Then have your driver grab all the PCI devices it wants, and they shouldn't be grabbed by the serial driver when it loads. If you can't get your driver to load before the serial driver for whatever reason, unloading the serial driver should give up the devices it had claimed. ..Stu - 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: Need break driver--pci-device automatic association
From: Jacques Goldberg To be ugly or to never be up to date, that's the question. We did patch 8250_pci.c but there is no way to build a stable list of the devices to be handled that way. We will thus spend some time on the hot unplug solution. I think what you want might be accomplished if the serial driver was compiled as a module. Then have your driver grab all the PCI devices it wants, and they shouldn't be grabbed by the serial driver when it loads. If you can't get your driver to load before the serial driver for whatever reason, unloading the serial driver should give up the devices it had claimed. ..Stu - 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: Greg's Policy! (was Re: Linus' policies?)
From: [EMAIL PROTECTED] > Remember that Linus has *always* reserved the right to change his mind > if a "sufficiently good" idea came along. So it's not as > much a "The Emperor > Penguin Has Decreed" as "Nobody's made a sufficiently > convincing case to Linus". > (And I've never seen Linus claim to be totally consistent on > what qualifies as > "sufficiently" - he can be a lot more stubborn about some > things and flexible on > on others) From: Theodore Ts'o > The distributions (by and large) honor it, but other than that, you > seem to have a slightly overinflated view how much weight and how much > formalities such statements actually have. > > The problem with collecting it, as other people have pointd out, is > that it implies that all such statements are valid forever (such as a > Pope's encyclical) or that we have some formal way of blessing a > statement by sprinkling Holy Penguin Pee on it, or some way of > retracting such a blessing (probably involving some ceremony involving > turning a candle upside down and snuffing it out :-). I was in a hurry and mimiced the wording of the referenced post, nothing more, nothing less. Policy would have been a better choice. I am under no illusions about validity or duration or whatnot. ..Stu - 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: Greg's Decree! (was Re: Linus' decrees?)
From: [EMAIL PROTECTED] > I'd vote for Documentation/Policies I'll second. ..Stu - 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: Greg's Decree! (was Re: Linus' decrees?)
From: [EMAIL PROTECTED] I'd vote for Documentation/Policies I'll second. ..Stu - 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: Greg's Policy! (was Re: Linus' policies?)
From: [EMAIL PROTECTED] Remember that Linus has *always* reserved the right to change his mind if a sufficiently good idea came along. So it's not as much a The Emperor Penguin Has Decreed as Nobody's made a sufficiently convincing case to Linus. (And I've never seen Linus claim to be totally consistent on what qualifies as sufficiently - he can be a lot more stubborn about some things and flexible on on others) From: Theodore Ts'o The distributions (by and large) honor it, but other than that, you seem to have a slightly overinflated view how much weight and how much formalities such statements actually have. The problem with collecting it, as other people have pointd out, is that it implies that all such statements are valid forever (such as a Pope's encyclical) or that we have some formal way of blessing a statement by sprinkling Holy Penguin Pee on it, or some way of retracting such a blessing (probably involving some ceremony involving turning a candle upside down and snuffing it out :-). sigh I was in a hurry and mimiced the wording of the referenced post, nothing more, nothing less. Policy would have been a better choice. I am under no illusions about validity or duration or whatnot. ..Stu - 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: Greg's Decree! (was Re: Linus' decrees?)
From: Greg Folkert [mailto:[EMAIL PROTECTED] > On Thu, 2005-02-24 at 15:03 -0500, Stuart MacDonald wrote: > > Recently I ran across > > > > http://groups.google.ca/groups?hl=en=lang_en=off= > > 1033074519.2698.5. > > camel%40localhost.localdomain > > > > Is there a collection point for Linus' decrees? > > > > The LSB (http://www.linuxbase.org/) seems to be mostly involved with > > how a distro is laid out, and not much to do with the kernel. > > Okay, Linus decreed... oh yeah. > Exactly what is wrong with the method anyway? > You on Crack? Uh, what? I'm not sure what you're trying to say with the above, except that maybe you think I was implying that the /lib/modules/`uname -r`/build method is somehow wrong. Which I wasn't, and I'm not even sure how you'd come to that conclusion from my post. And no, I'm not on crack. > Make TONS-O-SENSE to state the obvious. IOW the statement was all meant > to say *DO IT THIS WAY AND NO OTHER* as nobody else honors any other > method. The post I reference mentions that Linus once said that a standard method to locate the source for a particular kernel would be to have it at /lib/modules/`uname -r`/build. This seems to be a symlink for vanilla kernels, and actual source for the FC3 installed kernels I have handy. I had not heard this before, and it turns out to be handy for me. In the past I have also seen Linus state things like "binary drivers are bad" and "drm is okay". So what I'm wondering is, is there a location on the net where Linus' statements about how the kernel is to be are collected? ie, Where the above statements could all be found, with cites. I'm thinking there's probably other info about the standard way of doing things in regards to the kernel (all aspects thereof) that Linus has put forth that might be handy for me to know, and I'm hoping that there's a handy dandy collection that I can peruse. I guess what I'm looking for is a collection of linux kernel policies. Is there such a collection? ..Stu - 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/
Linus' decrees?
Recently I ran across http://groups.google.ca/groups?hl=en=lang_en=off=1033074519.2698.5. camel%40localhost.localdomain Is there a collection point for Linus' decrees? The LSB (http://www.linuxbase.org/) seems to be mostly involved with how a distro is laid out, and not much to do with the kernel. ..Stu - 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/
Linus' decrees?
Recently I ran across http://groups.google.ca/groups?hl=enlr=lang_ensafe=offselm=1033074519.2698.5. camel%40localhost.localdomain Is there a collection point for Linus' decrees? The LSB (http://www.linuxbase.org/) seems to be mostly involved with how a distro is laid out, and not much to do with the kernel. ..Stu - 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: Greg's Decree! (was Re: Linus' decrees?)
From: Greg Folkert [mailto:[EMAIL PROTECTED] On Thu, 2005-02-24 at 15:03 -0500, Stuart MacDonald wrote: Recently I ran across http://groups.google.ca/groups?hl=enlr=lang_ensafe=offselm= 1033074519.2698.5. camel%40localhost.localdomain Is there a collection point for Linus' decrees? The LSB (http://www.linuxbase.org/) seems to be mostly involved with how a distro is laid out, and not much to do with the kernel. Okay, Linus decreed... oh yeah. Exactly what is wrong with the method anyway? You on Crack? Uh, what? I'm not sure what you're trying to say with the above, except that maybe you think I was implying that the /lib/modules/`uname -r`/build method is somehow wrong. Which I wasn't, and I'm not even sure how you'd come to that conclusion from my post. And no, I'm not on crack. Make TONS-O-SENSE to state the obvious. IOW the statement was all meant to say *DO IT THIS WAY AND NO OTHER* as nobody else honors any other method. The post I reference mentions that Linus once said that a standard method to locate the source for a particular kernel would be to have it at /lib/modules/`uname -r`/build. This seems to be a symlink for vanilla kernels, and actual source for the FC3 installed kernels I have handy. I had not heard this before, and it turns out to be handy for me. In the past I have also seen Linus state things like binary drivers are bad and drm is okay. So what I'm wondering is, is there a location on the net where Linus' statements about how the kernel is to be are collected? ie, Where the above statements could all be found, with cites. I'm thinking there's probably other info about the standard way of doing things in regards to the kernel (all aspects thereof) that Linus has put forth that might be handy for me to know, and I'm hoping that there's a handy dandy collection that I can peruse. I guess what I'm looking for is a collection of linux kernel policies. Is there such a collection? ..Stu - 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: serial port O_SYNC functionality in 2.4.5
From: "James R Bruce" <[EMAIL PROTECTED]> > The overall size of the circular buffer would have to be decreased > too, but that's more of a hack to fix it now; Which I guess is what it > comes to. I see what you're saying; AFAIUnderstand, the low latency patches bypass the circular buffer. Or make it size one. > This is not really a problem; 16 bytes of hardware buffering I can > live with; at 19200 baud this is 7ms of lag. The 4096 byte software > buffer causes 1706ms of lag; That *is* a problem. It's a bit like the > difference between a hard disk drive's local buffer and the OS's (much > larger) buffering. O_SYNC on a disk garuntees that the output has > been flushed to the disk, but maybe not the physical medium. On a > serial port, similar functionality would be to have output to pushed > to the UART, but maybe not yet over the actual port. Gotchya. > The manpage seems to imply this would work, but it doesn't seem to > affect the software buffering at all (I tried this yesterday). AFAICT > from looking at the driver, the low_latency mode only applies to > reading, not writing: tty_flip_buffer_push(tty) is the only place the > latency flag is ever checked, and that is only called in receive_chars > in serial.c. The application that caused this doesn't get any serial > input whatsoever, so that won't (or at least shouldn't) get called. Hm. I haven't looked at the low_latency stuff, I was just repeating what I'd heard... > I changed WAKEUP_CHARS to 1 rather than 256 (0 would cause processes > to hang forever, btw), and SERIAL_XMIT_SIZE to 16 rather than > PAGE_SIZE. A proper solution would make this conditional on O_SYNC or > low_latency or even a kernel option. Suggestions? If you check the code, the circ buffer will never have a count < 0, so the hang is predictible; tty is never called for more tx chars. I'd say it should be part of low_latency. Although it's probably best to have rx low_latency and tx low_latency separately configurable. Honouring O_SYNC might not be a bad idea as well. Whatever option probably should make SERIAL_XMIT_SIZE == WAKEUP_CHARS; SERIAL needs to be a power of two, so 2, 4, 8 or 16 would be good choices. Probably should be similar to the rx low_latency. Best way to get this in the serial driver is to do some patches for it and send them to Ted. :-) ..Stu - 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: serial port O_SYNC functionality in 2.4.5
From: James R Bruce [EMAIL PROTECTED] The overall size of the circular buffer would have to be decreased too, but that's more of a hack to fix it now; Which I guess is what it comes to. I see what you're saying; AFAIUnderstand, the low latency patches bypass the circular buffer. Or make it size one. This is not really a problem; 16 bytes of hardware buffering I can live with; at 19200 baud this is 7ms of lag. The 4096 byte software buffer causes 1706ms of lag; That *is* a problem. It's a bit like the difference between a hard disk drive's local buffer and the OS's (much larger) buffering. O_SYNC on a disk garuntees that the output has been flushed to the disk, but maybe not the physical medium. On a serial port, similar functionality would be to have output to pushed to the UART, but maybe not yet over the actual port. Gotchya. The manpage seems to imply this would work, but it doesn't seem to affect the software buffering at all (I tried this yesterday). AFAICT from looking at the driver, the low_latency mode only applies to reading, not writing: tty_flip_buffer_push(tty) is the only place the latency flag is ever checked, and that is only called in receive_chars in serial.c. The application that caused this doesn't get any serial input whatsoever, so that won't (or at least shouldn't) get called. Hm. I haven't looked at the low_latency stuff, I was just repeating what I'd heard... I changed WAKEUP_CHARS to 1 rather than 256 (0 would cause processes to hang forever, btw), and SERIAL_XMIT_SIZE to 16 rather than PAGE_SIZE. A proper solution would make this conditional on O_SYNC or low_latency or even a kernel option. Suggestions? If you check the code, the circ buffer will never have a count 0, so the hang is predictible; tty is never called for more tx chars. I'd say it should be part of low_latency. Although it's probably best to have rx low_latency and tx low_latency separately configurable. Honouring O_SYNC might not be a bad idea as well. Whatever option probably should make SERIAL_XMIT_SIZE == WAKEUP_CHARS; SERIAL needs to be a power of two, so 2, 4, 8 or 16 would be good choices. Probably should be similar to the rx low_latency. Best way to get this in the serial driver is to do some patches for it and send them to Ted. :-) ..Stu - 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: Q serial.c
From: "Jonathan Lundell" <[EMAIL PROTECTED]> > The other CPU servicing the interrupt, was the question. cli() > doesn't affect that. This could presumably happen if shutdown() gets > run on a non-interrupt-servicing CPU, or if interrupts are > dynamically routed (eg round-robin). Ah. Missed that. Hm. Does appear to be a problem. Ted? > Where can I find the 5.05 driver? http://serial.sourceforge.net I'm not sure which version is currently in 2.4.latest, but it should be nearly 5.05. ..Stu - 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: Q serial.c
From: "kees" <[EMAIL PROTECTED]> > What may happen on a SMP machine if a serial port has been closed and the > closing stage is at shutdown() in serial.c in the call to free_IRQ and > BEFORE the IRQ is really shutdown, a new character arrives which causes an > IRQ? Is it possible that the OTHER cpu takes this interrupt and causes a > crash? I'm looking at serial-5.05/serial.c. You'll notice at the beginning of shutdown the saveflags(); cli(); calls. This disables interrupts. The uart will not be able to generate IRQs even if new characters arrive. ..Stu - 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: Q serial.c
From: kees [EMAIL PROTECTED] What may happen on a SMP machine if a serial port has been closed and the closing stage is at shutdown() in serial.c in the call to free_IRQ and BEFORE the IRQ is really shutdown, a new character arrives which causes an IRQ? Is it possible that the OTHER cpu takes this interrupt and causes a crash? I'm looking at serial-5.05/serial.c. You'll notice at the beginning of shutdown the saveflags(); cli(); calls. This disables interrupts. The uart will not be able to generate IRQs even if new characters arrive. ..Stu - 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: Q serial.c
From: Jonathan Lundell [EMAIL PROTECTED] The other CPU servicing the interrupt, was the question. cli() doesn't affect that. This could presumably happen if shutdown() gets run on a non-interrupt-servicing CPU, or if interrupts are dynamically routed (eg round-robin). Ah. Missed that. Hm. Does appear to be a problem. Ted? Where can I find the 5.05 driver? http://serial.sourceforge.net I'm not sure which version is currently in 2.4.latest, but it should be nearly 5.05. ..Stu - 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: VM suggestion...
From: "Marcelo Tosatti" <[EMAIL PROTECTED]> > The problem is that we _cannot_ base ourselves simply on practical results > from a _limited_ amount of workloads. Also remember the tests we (at least > I do) are benchmarks which try to use all resources all the time upon > completion. Isn't this the point of the X.odd.Y kernels? Spit the stats out into the syslog, along with a message of "If you see these, please mail them along to [EMAIL PROTECTED] and a description of your workload if it's not too much trouble." ..Stu - 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: VM suggestion...
From: Marcelo Tosatti [EMAIL PROTECTED] The problem is that we _cannot_ base ourselves simply on practical results from a _limited_ amount of workloads. Also remember the tests we (at least I do) are benchmarks which try to use all resources all the time upon completion. Isn't this the point of the X.odd.Y kernels? Spit the stats out into the syslog, along with a message of If you see these, please mail them along to [EMAIL PROTECTED] and a description of your workload if it's not too much trouble. ..Stu - 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] drivers/char/serial.c bug in ST16C654 detection
From: "Val Henson" <[EMAIL PROTECTED]> > Anyone know where Ted Tso is? He hasn't posted in several weeks. Haven't heard from him in a while. I've got a patch or two pending as well, one of which modifies this code to check for 16c2850s. Usually he just says he's really busy. > > Kernel version? Distribution? Are you using a serial console? > 2.4.5-pre1 (see patch). Are you using the serial console though? That seems to be implied by your problem, but I just want to check. > Because the comment was ambiguous. I don't have the data sheet for > the 85x family so I just wrote the code according to the comment. > I'll change the comment to make it clear. Hm. I didn't really read the comment, since I know what the code is doing. :-) I can send you an 864 sheet if you'd like; we most likely have the other 85x sheets around somewhere; all pdf format. ..Stu - 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] drivers/char/serial.c bug in ST16C654 detection
From: Val Henson [EMAIL PROTECTED] Anyone know where Ted Tso is? He hasn't posted in several weeks. Haven't heard from him in a while. I've got a patch or two pending as well, one of which modifies this code to check for 16c2850s. Usually he just says he's really busy. Kernel version? Distribution? Are you using a serial console? 2.4.5-pre1 (see patch). Are you using the serial console though? That seems to be implied by your problem, but I just want to check. Because the comment was ambiguous. I don't have the data sheet for the 85x family so I just wrote the code according to the comment. I'll change the comment to make it clear. Hm. I didn't really read the comment, since I know what the code is doing. :-) I can send you an 864 sheet if you'd like; we most likely have the other 85x sheets around somewhere; all pdf format. ..Stu - 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] drivers/char/serial.c bug in ST16C654 detection
From: "Val Henson" <[EMAIL PROTECTED]>
> Serial driver version 5.05a (2001-03-20) with MANY_PORTS SHARE_IRQ
> SERIAL_PCI enabled
Hmm. I've been looking at 5.05 (from http://serial.sourceforge.net),
I'm getting 2.4.4 and 2.4.5-pre2 to see what's in there.
> "Go kablooey" means that all serial output stops and the kernel never
> finishes booting. This patch makes it correctly detect the
> controller, continue to produce serial output, and finish booting.
Kernel version? Distribution? Are you using a serial console?
> I don't know why it doesn't work the way you describe. If I comment
> out the section of code that sets the baud rate to 0, everything works
> fine. Otherwise, it doesn't even finish booting. The Exar datasheet
> at http://www.exar.com/products/st16c654.pdf doesn't define what
> happens if you set the baud rate registers to 0.
Yeah, I double checked the 654 and 864 sheets yesterday. No mention,
which is sorta odd for the 864, since they explicitly say to write the 0s
to get the revision. I'd have to assume that it's bad. This bit I copied
from one of our hardware guys, and it worked, so I never looked too
closely at it. My apologies.
> It's just sloppy programming. There's no benefit from setting an
> invalid revision for the Exar and if the usage of state->revision
> changes it may introduce a bug.
I agree with you. However, the revision is Ted's code, and I've
generally found it easier to get our patches in to the driver if I
do what he's already doing. However, I agree with you.
> The comment above it should also be changed then. If someone knows
> for sure whether the revision should be saved for the XR16C854 then
> the comment can be made clearer. See patch below.
The revision should always be saved if it's available. Hmm.
I didn't look carefully yesterday. The DLL always contains the
revision for the 85x family. Why do you think it doesn't?
I think your patch below is good, I'm just mystified by this
kablooey thing.
..Stu
--- linux-2.4.5-pre1/drivers/char/serial.c Thu Apr 19 00:26:34 2001
+++ linux/drivers/char/serial.c Tue May 15 03:19:08 2001
@@ -3507,7 +3507,7 @@
struct serial_state *state,
unsigned long flags)
{
- unsigned char scratch, scratch2, scratch3;
+ unsigned char scratch, scratch2, scratch3, scratch4;
/*
* First we check to see if it's an Oxford Semiconductor UART.
@@ -3548,20 +3548,33 @@
* then reading back DLL and DLM. If DLM reads back 0x10,
* then the UART is a XR16C850 and the DLL contains the chip
* revision. If DLM reads back 0x14, then the UART is a
- * XR16C854.
- *
+ * XR16C854 and the DLL may or may not contain the revision.
*/
+
+ /* Save the DLL and DLM */
+
serial_outp(info, UART_LCR, UART_LCR_DLAB);
+ scratch3 = serial_inp(info, UART_DLL);
+ scratch4 = serial_inp(info, UART_DLM);
+
serial_outp(info, UART_DLL, 0);
serial_outp(info, UART_DLM, 0);
- state->revision = serial_inp(info, UART_DLL);
+ scratch2 = serial_inp(info, UART_DLL);
scratch = serial_inp(info, UART_DLM);
serial_outp(info, UART_LCR, 0);
+
if (scratch == 0x10 || scratch == 0x14) {
+ state->revision = scratch2;
state->type = PORT_16850;
return;
}
+ /* Restore the DLL and DLM */
+
+ serial_outp(info, UART_LCR, UART_LCR_DLAB);
+ serial_outp(info, UART_DLL, scratch3);
+ serial_outp(info, UART_DLM, scratch4);
+ serial_outp(info, UART_LCR, 0);
/*
* We distinguish between the '654 and the '650 by counting
* how many bytes are in the FIFO. I'm using this for now,
-
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] drivers/char/serial.c bug in ST16C654 detection
From: Val Henson [EMAIL PROTECTED]
Serial driver version 5.05a (2001-03-20) with MANY_PORTS SHARE_IRQ
SERIAL_PCI enabled
Hmm. I've been looking at 5.05 (from http://serial.sourceforge.net),
I'm getting 2.4.4 and 2.4.5-pre2 to see what's in there.
Go kablooey means that all serial output stops and the kernel never
finishes booting. This patch makes it correctly detect the
controller, continue to produce serial output, and finish booting.
Kernel version? Distribution? Are you using a serial console?
I don't know why it doesn't work the way you describe. If I comment
out the section of code that sets the baud rate to 0, everything works
fine. Otherwise, it doesn't even finish booting. The Exar datasheet
at http://www.exar.com/products/st16c654.pdf doesn't define what
happens if you set the baud rate registers to 0.
Yeah, I double checked the 654 and 864 sheets yesterday. No mention,
which is sorta odd for the 864, since they explicitly say to write the 0s
to get the revision. I'd have to assume that it's bad. This bit I copied
from one of our hardware guys, and it worked, so I never looked too
closely at it. My apologies.
It's just sloppy programming. There's no benefit from setting an
invalid revision for the Exar and if the usage of state-revision
changes it may introduce a bug.
I agree with you. However, the revision is Ted's code, and I've
generally found it easier to get our patches in to the driver if I
do what he's already doing. However, I agree with you.
The comment above it should also be changed then. If someone knows
for sure whether the revision should be saved for the XR16C854 then
the comment can be made clearer. See patch below.
The revision should always be saved if it's available. Hmm.
I didn't look carefully yesterday. The DLL always contains the
revision for the 85x family. Why do you think it doesn't?
I think your patch below is good, I'm just mystified by this
kablooey thing.
..Stu
--- linux-2.4.5-pre1/drivers/char/serial.c Thu Apr 19 00:26:34 2001
+++ linux/drivers/char/serial.c Tue May 15 03:19:08 2001
@@ -3507,7 +3507,7 @@
struct serial_state *state,
unsigned long flags)
{
- unsigned char scratch, scratch2, scratch3;
+ unsigned char scratch, scratch2, scratch3, scratch4;
/*
* First we check to see if it's an Oxford Semiconductor UART.
@@ -3548,20 +3548,33 @@
* then reading back DLL and DLM. If DLM reads back 0x10,
* then the UART is a XR16C850 and the DLL contains the chip
* revision. If DLM reads back 0x14, then the UART is a
- * XR16C854.
- *
+ * XR16C854 and the DLL may or may not contain the revision.
*/
+
+ /* Save the DLL and DLM */
+
serial_outp(info, UART_LCR, UART_LCR_DLAB);
+ scratch3 = serial_inp(info, UART_DLL);
+ scratch4 = serial_inp(info, UART_DLM);
+
serial_outp(info, UART_DLL, 0);
serial_outp(info, UART_DLM, 0);
- state-revision = serial_inp(info, UART_DLL);
+ scratch2 = serial_inp(info, UART_DLL);
scratch = serial_inp(info, UART_DLM);
serial_outp(info, UART_LCR, 0);
+
if (scratch == 0x10 || scratch == 0x14) {
+ state-revision = scratch2;
state-type = PORT_16850;
return;
}
+ /* Restore the DLL and DLM */
+
+ serial_outp(info, UART_LCR, UART_LCR_DLAB);
+ serial_outp(info, UART_DLL, scratch3);
+ serial_outp(info, UART_DLM, scratch4);
+ serial_outp(info, UART_LCR, 0);
/*
* We distinguish between the '654 and the '650 by counting
* how many bytes are in the FIFO. I'm using this for now,
-
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] drivers/char/serial.c bug in ST16C654 detection
From: "Val Henson" <[EMAIL PROTECTED]>
> This fixes a bug in the autoconfig_startech_uarts function in
> serial.c. The problem is that 0's are written to the baud rate
> registers in order to detect an XR16C850 or XR16C854. This makes the
> Exar ST16C654 go kablooey. Saving and restoring the baud rate
> registers after the test fixes it.
What version of serial.c? I'm assuming 5.05.
Define "go kablooey". We haven't noticed any problems, and we supplied
this bit of code.
The size_fifo() routine supplies its own baud rate divisor, and
on any rs_open() change_speed() sets the baud rate properly.
I can't figure what you might be seeing.
> I'm assuming that the XR16C85[04] detection works as is and doesn't
> need the original baud rate restored. If I'm wrong, I'll rewrite the
> patch.
You're correct that the detection works as is, except that you
broke it in your patch. See below.
> --- linux-2.4.5-pre1/drivers/char/serial.c Thu Apr 19 00:26:34 2001
> +++ linux/drivers/char/serial.c Sat May 12 05:19:26 2001
> @@ -3507,7 +3507,7 @@
> struct serial_state *state,
> unsigned long flags)
> {
> - unsigned char scratch, scratch2, scratch3;
> + unsigned char scratch, scratch2, scratch3, scratch4;
>
> /*
> * First we check to see if it's an Oxford Semiconductor UART.
> @@ -3551,17 +3551,32 @@
> * XR16C854.
> *
> */
> +
> + /* Save the DLL and DLM */
> +
> serial_outp(info, UART_LCR, UART_LCR_DLAB);
> + scratch3 = serial_inp(info, UART_DLL);
> + scratch4 = serial_inp(info, UART_DLM);
> +
> serial_outp(info, UART_DLL, 0);
> serial_outp(info, UART_DLM, 0);
> - state->revision = serial_inp(info, UART_DLL);
> + scratch2 = serial_inp(info, UART_DLL);
This isn't necessary. The revision field is only checked
for 950s, so setting it here doesn't harm anything. If the
current (only) example of checking it is followed as normal
procedure, the port type will always be checked first, before
checking the revision, ensuring only valid revisions are
referenced.
> scratch = serial_inp(info, UART_DLM);
> serial_outp(info, UART_LCR, 0);
> +
> if (scratch == 0x10 || scratch == 0x14) {
> + if (scratch == 0x10)
> + state->revision = scratch2;
> state->type = PORT_16850;
> return;
> }
Only saving the revision for 850s is probably wrong. It should
be saved for all the 85x uarts.
> + /* Restore the DLL and DLM */
> +
> + serial_outp(info, UART_LCR, UART_LCR_DLAB);
> + serial_outp(info, UART_DLL, scratch3);
> + serial_outp(info, UART_DLM, scratch4);
> + serial_outp(info, UART_LCR, 0);
> /*
> * We distinguish between the '654 and the '650 by counting
> * how many bytes are in the FIFO. I'm using this for now,
..Stu
-
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] drivers/char/serial.c bug in ST16C654 detection
From: Val Henson [EMAIL PROTECTED]
This fixes a bug in the autoconfig_startech_uarts function in
serial.c. The problem is that 0's are written to the baud rate
registers in order to detect an XR16C850 or XR16C854. This makes the
Exar ST16C654 go kablooey. Saving and restoring the baud rate
registers after the test fixes it.
What version of serial.c? I'm assuming 5.05.
Define go kablooey. We haven't noticed any problems, and we supplied
this bit of code.
The size_fifo() routine supplies its own baud rate divisor, and
on any rs_open() change_speed() sets the baud rate properly.
I can't figure what you might be seeing.
I'm assuming that the XR16C85[04] detection works as is and doesn't
need the original baud rate restored. If I'm wrong, I'll rewrite the
patch.
You're correct that the detection works as is, except that you
broke it in your patch. See below.
--- linux-2.4.5-pre1/drivers/char/serial.c Thu Apr 19 00:26:34 2001
+++ linux/drivers/char/serial.c Sat May 12 05:19:26 2001
@@ -3507,7 +3507,7 @@
struct serial_state *state,
unsigned long flags)
{
- unsigned char scratch, scratch2, scratch3;
+ unsigned char scratch, scratch2, scratch3, scratch4;
/*
* First we check to see if it's an Oxford Semiconductor UART.
@@ -3551,17 +3551,32 @@
* XR16C854.
*
*/
+
+ /* Save the DLL and DLM */
+
serial_outp(info, UART_LCR, UART_LCR_DLAB);
+ scratch3 = serial_inp(info, UART_DLL);
+ scratch4 = serial_inp(info, UART_DLM);
+
serial_outp(info, UART_DLL, 0);
serial_outp(info, UART_DLM, 0);
- state-revision = serial_inp(info, UART_DLL);
+ scratch2 = serial_inp(info, UART_DLL);
This isn't necessary. The revision field is only checked
for 950s, so setting it here doesn't harm anything. If the
current (only) example of checking it is followed as normal
procedure, the port type will always be checked first, before
checking the revision, ensuring only valid revisions are
referenced.
scratch = serial_inp(info, UART_DLM);
serial_outp(info, UART_LCR, 0);
+
if (scratch == 0x10 || scratch == 0x14) {
+ if (scratch == 0x10)
+ state-revision = scratch2;
state-type = PORT_16850;
return;
}
Only saving the revision for 850s is probably wrong. It should
be saved for all the 85x uarts.
+ /* Restore the DLL and DLM */
+
+ serial_outp(info, UART_LCR, UART_LCR_DLAB);
+ serial_outp(info, UART_DLL, scratch3);
+ serial_outp(info, UART_DLM, scratch4);
+ serial_outp(info, UART_LCR, 0);
/*
* We distinguish between the '654 and the '650 by counting
* how many bytes are in the FIFO. I'm using this for now,
..Stu
-
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: kernel/sched.c questions
I had similar questions recently when I was doing some
hacking; these are my guesses:
From: ; "Eliel" <[EMAIL PROTECTED]>
> Hello, I would like to know why you put this two functions:
> void scheduling_functions_start_here(void) { }
> ...
> void scheduling_functions_end_here(void) { }
Just as markers for easy location in System.map.
The compiler should optimise those away.
> why you put 'case TASK_RUNNING'
>
> switch (prev->state) {
> case TASK_INTERRUPTIBLE:
> if (signal_pending(prev)) {
> prev->state = TASK_RUNNING;
> break;
> }
> default:
> del_from_runqueue(prev);
> case TASK_RUNNING:
> }
Prevent compiler warnings about unhandled conditions?
Not sure about that one.
> in the function schedule() you always use this syntax:
>
> -
> if (a_condition)
> goto bebe;
> bebe_back
>
>
> bebe:
> do_bebe();
> goto bebe_back;
> --
> why not just doing:
>
>if (a_condition)
> do_bebe();
Probably because the compiler puts out
setup function parameter one
setup function parameter two
setup function parameter three
check condition
call function
setup function parameter one
setup function parameter two
setup function parameter three
check condition
call function
for your case and the above convolutions
puts out
check condition
jump to call if needed
check condition
jump to call if needed
instead.
Or even if the compiler puts out
check condition
If condition
setup function parameter one
setup function parameter two
setup function parameter three
call function
check condition
if condition
setup function parameter one
setup function parameter two
setup function parameter three
call function
I'm betting the smaller code above is better
for cache hits, right?
But these are my guesses. Anyone want to
clarify?
..Stu
-
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: kernel/sched.c questions
I had similar questions recently when I was doing some
hacking; these are my guesses:
From: Sardaons; "Eliel" [EMAIL PROTECTED]
Hello, I would like to know why you put this two functions:
void scheduling_functions_start_here(void) { }
...
void scheduling_functions_end_here(void) { }
Just as markers for easy location in System.map.
The compiler should optimise those away.
why you put 'case TASK_RUNNING'
switch (prev-state) {
case TASK_INTERRUPTIBLE:
if (signal_pending(prev)) {
prev-state = TASK_RUNNING;
break;
}
default:
del_from_runqueue(prev);
case TASK_RUNNING:
}
Prevent compiler warnings about unhandled conditions?
Not sure about that one.
in the function schedule() you always use this syntax:
-
if (a_condition)
goto bebe;
bebe_back
bebe:
do_bebe();
goto bebe_back;
--
why not just doing:
if (a_condition)
do_bebe();
Probably because the compiler puts out
setup function parameter one
setup function parameter two
setup function parameter three
check condition
call function
setup function parameter one
setup function parameter two
setup function parameter three
check condition
call function
for your case and the above convolutions
puts out
check condition
jump to call if needed
check condition
jump to call if needed
instead.
Or even if the compiler puts out
check condition
If condition
setup function parameter one
setup function parameter two
setup function parameter three
call function
check condition
if condition
setup function parameter one
setup function parameter two
setup function parameter three
call function
I'm betting the smaller code above is better
for cache hits, right?
But these are my guesses. Anyone want to
clarify?
..Stu
-
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: URGENT : System hands on "Freeing unused kernel memory: "
From: "Thomas Foerster" <[EMAIL PROTECTED]> > But suddenly the box was offline. One technical assistant from our ISP tried to reboot > our server (he couldn't tell me if there had been any messages on the screen), but the > system always hangs on > > Freeing unused kernel memory: xxk freed I have a customer with the same symptom. They have stock Mandrake 7.2 (kernel 2.2.17-21mdk) and have installed serial-5.05 into it. The kernel boots to the Freeing message and hangs. I noticed ctl-alt-del still works, so I configured in magic sysrq (Documentation/sysrq.txt). sysrq-p allowed me to get the eip, which checking against the System.map I find is mod_timer(). A quick printk showed me that the kernel isn't hung, it's in an infinite loop, with mod_timer() being one of the calls in the loop. YMMV, but hopefully this method can help you find your problem. ..Stu - 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: URGENT : System hands on Freeing unused kernel memory:
From: "Thomas Foerster" [EMAIL PROTECTED] But suddenly the box was offline. One technical assistant from our ISP tried to reboot our server (he couldn't tell me if there had been any messages on the screen), but the system always hangs on Freeing unused kernel memory: xxk freed I have a customer with the same symptom. They have stock Mandrake 7.2 (kernel 2.2.17-21mdk) and have installed serial-5.05 into it. The kernel boots to the Freeing message and hangs. I noticed ctl-alt-del still works, so I configured in magic sysrq (Documentation/sysrq.txt). sysrq-p allowed me to get the eip, which checking against the System.map I find is mod_timer(). A quick printk showed me that the kernel isn't hung, it's in an infinite loop, with mod_timer() being one of the calls in the loop. YMMV, but hopefully this method can help you find your problem. ..Stu - 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/
[OT] Re: Microsoft begining to open source Windows 2000?
From: "Venkatesh Ramamurthy" <[EMAIL PROTECTED]> > http://www.zdnet.com/enterprise/stories/main/0,10228,2692987,00.html "As such, clients will not be allowed to alter the code in any form and may not give any other party access to any aspect of that code." Does this preclude one reading the source and then using the knowledge gained to write, independently, working modules for Linux; fixing the fs problems for instance? Does anyone on the list have access to the code? It seems to me this might be an opportunity... ..Stu - 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/
[OT] Re: Microsoft begining to open source Windows 2000?
From: "Venkatesh Ramamurthy" [EMAIL PROTECTED] http://www.zdnet.com/enterprise/stories/main/0,10228,2692987,00.html "As such, clients will not be allowed to alter the code in any form and may not give any other party access to any aspect of that code." Does this preclude one reading the source and then using the knowledge gained to write, independently, working modules for Linux; fixing the fs problems for instance? Does anyone on the list have access to the code? It seems to me this might be an opportunity... ..Stu - 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: FAIL: 2.2.18 + AA-VM-global-7 + serial 5.05
From: "Matthias Andree" <[EMAIL PROTECTED]> > 3. patch the kernel with that 2.2.18-fix-serial-5.05-pre.patch, it takes >a high fuzz factor (try patch -p1 -F10) > 4. unpack serial-5.05 I don't have permission to fetch 2.2.18-fix-serial-5.05-pre.patch at http://www-dt.e-technik.uni-dortmund.de/~ma/kernelpatches/v2.2/v2.2.18/ What file does step 3 modify? It's likely this patch is being overwritten (lost) in step 4. Probably not the source of the problem though. ..Stu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: FAIL: 2.2.18 + AA-VM-global-7 + serial 5.05
From: "Matthias Andree" [EMAIL PROTECTED] 3. patch the kernel with that 2.2.18-fix-serial-5.05-pre.patch, it takes a high fuzz factor (try patch -p1 -F10) 4. unpack serial-5.05 I don't have permission to fetch 2.2.18-fix-serial-5.05-pre.patch at http://www-dt.e-technik.uni-dortmund.de/~ma/kernelpatches/v2.2/v2.2.18/ What file does step 3 modify? It's likely this patch is being overwritten (lost) in step 4. Probably not the source of the problem though. ..Stu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Russell King forks ARM Linux.u
From: "H. Peter Anvin" <[EMAIL PROTECTED]> > Does that mean SPARC has a conflict between the 8250/16x50 driver and the > Zilog driver? If so, the latter should probably move (ttyZ is still an > unused name.) If there's a conflict it would be with the minor numbers, which I haven't been able to check yet, not the /dev namespace. Well, if if both drivers want their users to use ttyS0 as the first UART from each, the user will have to pick one, but that's not up to the driver. ..Stu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
