RE: [PATCH] jsm: Remove further unneeded crud
> > Remove some remaining vestiges of the old hacks jsm had to work around > the old tty buffering. With the new tty buffering it simply doesn't > matter any more. > > Signed-off-by: Alan Cox <[EMAIL PROTECTED]> Thanks Alan for helping cleaning up jsm. Acked-by: Scott Kilau <[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/
RE: [PATCH][RFC] Remove support for the orphaned, obsolete Digi EPCA driver.
Hi all, > Last time I poked at the tools they were working under 2.6 with some > trivial compile fixes. Ideally this driver would be trimmed > to ISA only > and the newer dgrs drivers merged but latter half appears to > be something > digi have no interest in I would be very surprised if anyone uses/could use the existing "epca" drivers in the kernel. As Robert has noticed, they would *not* work out-of-the-box, and would require tweaking in the userspace utils as well as the kernel code as well. We here at Digi would love to see the "epca" driver go away from the kernel sources and replace it with our new "dgap" open source driver, but I can understand where you are coming from Alan. As for merging the new Digi driver (dgap) source code that actually work under 2.6 kernel, I attempted that a few years ago... It did not go well, which I know and understand is expected for merging ANY new driver into the kernel. However, it was discovered during that time, there are fundamental things/changes required to the driver that would end up crippling our driver in the "usability" department. (Probably the biggest obstacle, was the extra ioctls to manage "Digi" specific things, and other hooks that are simply not permitted in in-kernel code) Trust me, I *know* the pain of keeping the driver out-of-tree with the constant flux in the kernel API, and I understand that most people here say its completely self-inflicted... But massively crippling the driver from a usability POV, just simply isn't an option. Thus, I have to keep the driver, open source, but out-of-tree, and take the lumps of the constantly changing kernel API as they are dished out. Scott Kilau Digi International - 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
> > > > > 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. > > I'm also not aware of any reason other than history, which means if > someone cares to double check the other drivers there really shouldn't be > an obstacle to "fixing" this behaviour. > > Unless anyone knows different ? Hi Alan! >From our (Digi's) drivers history, I believe you tried "fixing" it back in the Red Hat 7.1 days. =) Sadly, our drivers still carry this legacy fix around. o Red Hat 7.1 -- Kernel Compatibility Issues Some 2.4 kernel-based distributions (Red Hat 7.1 included) have a patch applied to them which modifies the behavior of Linux when an open of a serial port is canceled (for instance, if an application is waiting for the carrier signal and a user hits CTRL-C to kill the application) With this behavior change, the device driver is unable to cleanup its internal data structures and the sane functioning of the driver is compromised. The classic symptom of this problem is that the command "lsmod", which (among other things) will return a count of the applications using the device driver, will return a non-zero value even if all applications associated with the serial ports are killed. Unfortunately, it is impossible (from within the device driver) to determine which behavior is implemented in the running kernel. However, Digi now provides a workaround to allow customers with this problem to change the Digi behavior to be compatible with these "patched" kernels. I know backwards compatibility in the kernel isn't a concern at all, which has been made abundantly clear, (ie, stable_api_nonsense.txt), but this will impact *all* out of tree serial drivers. Just wanted to toss this out there. Scott Kilau - 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.20 doesn't compile with gcc-3.2.2
Hi Al, > What was your binutils version (# ld -v) before and after the upgrade? I was on the "last" version of binutils that Red Hat 9 had, which was: binutils-2.13.90.0.18-9.i386 I went up to the prebuilt version of binutils from Fedora Core 3: [EMAIL PROTECTED] tmp]# ld -v GNU ld version 2.15.92.0.2 20040927 [EMAIL PROTECTED] tmp]# rpm -qa|grep binutil binutils-2.15.92.0.2-5.1 Scott - 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.20 doesn't compile with gcc-3.2.2
Hi all, > > objcopy: arch/i386/boot/compressed/vmlinux.bin: File truncated > > make[2]: *** [arch/i386/boot/compressed/vmlinux.bin] Error 1 > > make[1]: *** [arch/i386/boot/compressed/vmlinux] Error 2 > > make: *** [bzlilo] Error 2 I got the same as well here on my box. I am using Red Hat 9, with a lot of things upgraded. I found other "hints" that this might be a binutils issue, which obviously hasn't been touched in years on Red Hat 9, so I picked up the binutils built for Fedora Core 3, and installed them... That solved the problem. Scott Kilau - 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: Strange problem with tty layer
Hi Len, > I am seeing a very strange problem which seems to be in the tty layer. > > I am using an exar 17D154 based PCI card (like the digi neo style card) > using the jsm driver. Kernel version 2.6.16.25. There are a couple interesting things I would do here. 1) The tty "flip" buffer stuff was changed in 2.6.16+. Maybe you could try going downwards to 2.6.15 or below and see if the problem still exists. Then try going up to 2.6.19, I believe there were some bugs fixed in 2.6.17/18/19, not sure how many of those made it backported into 2.6.16.25. 2) Try using Digi's "Out-Of-Kernel-Source-Tree"/GPL version of the driver. You can grab the latest and greatest beta version of it from here: ftp://ftp1.digi.com/support/beta/linux/dgnc/ Its in source rpm format, let me know if you need it in a tarball format instead. You obviously will have to add in your specific PCI id into the driver, but that should be a problem. 3) I seem to recall that someone mentioned that the Exar 17D154 PCI chips were easily "pushed" into the 8250 driver. It might be interesting to try that route as well. Scott Kilau - 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: RFC: removing the dgrs net driver
Hi everyone, > As I understand it a small number of such devices were produced, but I > have no objection to it going away. Even if someone had such a card it > would not actually be useful any more. > Alan Alan is correct. The "Digi RightSwitch" product did actually make it out to the real world. Its basically a NIC card with a built-in switch, back when switches actually cost $$$. Obviously its been commoditized in the marketplace to the point where its basically worthless now. =) There were not that many produced or sold, and got "killed" pretty quick here at Digi. I know Digi as a company would not care if the driver "went away" from the kernel sources as the product hasn't been sold in many many years... However, there *might* actually still be users for said driver... Its just hard to say. Scott Kilau Digi International - 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: Digi Neo 8: linux-2.6.12_r2 jsm driver
Hi Christoph, everyone, > While Scott wrote most of the original code that ended up in the jsm driver > he's certainly not the maintainer in any sense. Christoph, au contraire. You might want to check with Wendy again, on who the maintainer of the JSM driver code will be. =) At any rate, I have had enough insults from you now. I have a workaround in place for the JSM driver conflict, so I consider this matter closed. Scott - 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: Digi Neo 8: linux-2.6.12_r2 jsm driver
Hi Matt, The ball is in my court, because my wishes as a copyright holder are not being honored. Which is the right of Christoph because of the GPL, but it sure doesn't help the end users of said product. Your claim that you are trying to "help" end users is bogus and just plain wrong. Period. > As such, we make very little allowance > for their concerns, especially when they stand in > the way of improving things that _are_ in the kernel. How is shipping a stripped down version of the driver, by yanking things our customers want, improving the "things that are in the kernel"? At any rate, After thinking about this some more, I actually don't believe all this will be a problem on my end after all. When the user installs my driver with all the extra features that our customers really want, I will simply check to see if jsm.ko exists, and ask the user if I can blow away the jsm.ko module. So now, I think this thread can probably die a peaceful death. Scott - 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: Digi Neo 8: linux-2.6.12_r2 jsm driver
> There's a consensus that if there's *any* choice, new /proc files as > well as new ioctls shall not be introduced. So if there's management needed Oh, keep in mind, the ioctls are not new. They exist today, and are clearly defined in Documentation/ioctl-number.txt > 'd' F0-FF linux/digi1.h But we have already been down this road in a previous thread, and I gave up on that argument as well. =) Scott Kilau -Original Message- From: Jan-Benedict Glaw [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 12, 2005 1:49 PM To: Kilau, Scott Cc: Christoph Hellwig; Ihalainen Nickolay; [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; Wen Xiong Subject: Re: Digi Neo 8: linux-2.6.12_r2 jsm driver On Tue, 2005-04-12 11:42:31 -0500, Kilau, Scott <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > The JSM driver was forced to be stripped down when being submitted > to the kernel sources, and many extended features removed as so to be > included into the kernel, as the extended features added special ioctls > and special /proc (/sys for 2.6) files. There's a consensus that if there's *any* choice, new /proc files as well as new ioctls shall not be introduced. So if there's management needed (disclaimer: I don't own such a card), then this interface needs to be introduced as a generic interface, which might be used by any further drivers. We've just had this situation for some RAID cards, where the vendor wanted to introduce a (specific for his devices) interface. Either do it correct (as of best current practice), or don't do it at all. > > I didn't think that you would remove them. I read the posts and > > wondered *why* they wanted the management pieces removed. > > One reason to use the Digi products is for the sole fact that > > they *can* be diagnosed. > > I'm glad that Digi is still focused properly. > > I agree that committing the drivers to the main kernel > > is not the way to go if you are forced to remove dpa and ditty. Well, again, if this features can only used by your hardware (and there's proof that no other vendor will add these features *ever*), then an own interface is okay. But if there's a possibility that a different vendor *might* introduce these as well, then a generic interface needs to be build (with first of all only one user: your driver). > I will let the chips fall where they will, and clean up the mess that > will soon be introduced into my driver world. =) That's a plan. Good to head :-) MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED]. +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf| Gegen Zensur | Gegen Krieg _ _ O fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)); - 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: Digi Neo 8: linux-2.6.12_r2 jsm driver
Hi Greg, all, > Ok, but wasn't it possible to get those additional things added to the > main kernel serial core, which would then provide everything that Digi's > customers are accustomed to? Yes, it is my intention in the future to add support for the needed information, probably at the /sys level. The key is to be able to get at the tty information without having to open up the tty/port. Again, I understand why you required the changes in JSM, IBM didn't need DPA support, so I had no problem with removing the support. However, neither IBM nor Digi wants this thread's patch to be applied, and yet Christoph wants to do it, completely out of spite, to break our out-of-tree open source driver. This is the problem that I have. Scott - 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: Digi Neo 8: linux-2.6.12_r2 jsm driver
Hi Jan, > But please be prepared to be in a competitive position. You've won't get > your driver included by just telling once about it; you'll need to work > towards that goal, and probably monitor the driver to be useable in the > future. The JSM driver is a "stripped" down version of the DGNC driver. There is no "competition" between these 2 drivers. They were always intended to work side by side with each other. Both drivers will get all fixes/changes added to them at the same time, since 90% of the driver code is the same. The JSM driver was forced to be stripped down when being submitted to the kernel sources, and many extended features removed as so to be included into the kernel, as the extended features added special ioctls and special /proc (/sys for 2.6) files. Oddly enough, I have had a few of our customers come back to me, after seeing some of the previous JSM threads about yanking the extended features, and I quote: > I didn't think that you would remove them. I read the posts and > wondered *why* they wanted the management pieces removed. > One reason to use the Digi products is for the sole fact that > they *can* be diagnosed. > I'm glad that Digi is still focused properly. > I agree that committing the drivers to the main kernel > is not the way to go if you are forced to remove dpa and ditty. But this is neither here nor there, as Christoph has made it clear, actual "Digi customers" don't matter. I will let the chips fall where they will, and clean up the mess that will soon be introduced into my driver world. =) Scott - 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: Digi Neo 8: linux-2.6.12_r2 jsm driver
Hi Greg, > What features? Didn't we end up with a valid resolution to all of the > additional stuff in the jsm driver that you originally asked for? Why > not work on adding those new features to the serial core, and then there > would be no issue with accepting your other driver? I appreciate your "calm" response. =) DPA (Digi Port Authority) support (the special ioctls) and /proc (and /sys) files were left unresolved. Wendy had no choice but to remove them to get the driver into the kernel sources. IBM was okay with removing them, so I was okay with doing it as well, as the whole point of the JSM driver is to support IBM's card directly. However, removing those things are just unacceptable for Digi for our cards. I understand your position, and I respect it. This is why for now, I cannot submit the original DGNC driver. However, I have taken your suggestion of moving to the serial-core to heart, and in the future, when I am able to drop 2.4 kernel support in the DGNC driver, I will completely go to serial-core, like the JSM driver has already done. Thanks! Scott Kilau - 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: Digi Neo 8: linux-2.6.12_r2 jsm driver
> You didn't not give a single good reason. Only political bullshit. How does "having more features" as a reason equal "political bullshit" ? I am done with this thread, because I know continuing the flaming is what you live for. Do what you want, because I know you will. However, again, I want to state to everyone else on the list: "I, Scott Kilau, as the copyright holder of the JSM driver, do NOT sign off on this change". Scott Kilau - 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: Digi Neo 8: linux-2.6.12_r2 jsm driver
Wendy and I released under the GPL, and as such, I know legally you have the right to modify the code the way you see fit. However, when the copyright holder says "No, please don't add that code", and gives *GOOD* reasons why, you should respect that decision. So if I don't sign off on this change, does the matter? If not, what good is having the sign off section for patches that must go through the maintainer? I would have no problem submitting the other driver (DGNC) for kernel inclusion, and have tried repeatedly in the past. However, I am NOT willing to strip out many of the features our customers, (and as such, your USERS) want, which is what happened with the JSM driver. > There are people who just want the card supported. There's no reason > to deny the driver to them. Oh, it *is* supported, using our GPL'ed DGNC driver available on our ftp/web site. This is not some argument of closed binaries versus open source binaries, As both the JSM and DGNC drivers are completely open source and GPL'ed. This is about having the users of this card end up getting a worse experience by using the JSM driver. However, in case it actually matters, (which I know it won't), "I, Scott Kilau, *DO NOT* sign off on this patch to the JSM driver". Scott Kilau Digi International - 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: Digi Neo 8: linux-2.6.12_r2 jsm driver
We (Digi) cares. We want people to use our DGNC driver over the JSM driver in all cases except the 2 port model of the board. This is because the DGNC driver contains extra features that the JSM driver Has stripped out, to get into the kernel sources, and our other customers WANT these features! We cannot have a situation where the JSM driver takes control of the PCI card before the DGNC driver can take it first! Please, do *NOT* add this patch!!! Do I, as a copyright holder on the code in question, have any rights at all, or are you just going to trample over my wishes, in your zeal? Scott -Original Message- From: Christoph Hellwig [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 12, 2005 9:44 AM To: Kilau, Scott Cc: Ihalainen Nickolay; [EMAIL PROTECTED]; linux-kernel@vger.kernel.org Subject: Re: Digi Neo 8: linux-2.6.12_r2 jsm driver On Tue, Apr 12, 2005 at 09:02:42AM -0500, Kilau, Scott wrote: > LKML, please, do *NOT* apply this patch to the kernel! > It will cause conflicts if our customers have both the Digi DGNC and > IBM/Digi JSM drivers installed! Who cares? If you're driver was written properly (which I hope for you) it'll just skip a device that's bound to the jsm driver already. And having additional hardware support is always a good thing, especially if it's as trivial as that patch. - 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: Digi Neo 8: linux-2.6.12_r2 jsm driver
Hi,
Not having the 8 port board listed in the JSM driver was actually
intentional.
IBM and Digi only want the 2 port Neo board supported in the JSM driver,
as IBM are only using the 2 port Neo products.
Digi has a different and more fully featured driver for the other port
count boards. (1, 4, 8).
If you would like, I can send you the source tarball of this version of
the driver instead,
its called DGNC, and contains more diagnostics and utilities.
LKML, please, do *NOT* apply this patch to the kernel!
It will cause conflicts if our customers have both the Digi DGNC and
IBM/Digi JSM drivers installed!
Thanks!
Scott Kilau
-Original Message-
From: Ihalainen Nickolay [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 12, 2005 7:14 AM
To: Kilau, Scott
Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org
Subject: Digi Neo 8: linux-2.6.12_r2 jsm driver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I compile linux-2.6.12_r2 sources with jsm support, but Digi Neo 8 is
unsupported.
after some code-modifications it works fine.
lspci -v
:00:09.0 Serial controller: Digi International Digi Neo 8 (rev 02)
(prog-if 02 [16550])
~Subsystem: Digi International Digi Neo 8
~Flags: fast devsel, IRQ 16
~Memory at feb7e000 (32-bit, non-prefetchable)
diff -r linux-2.6.12-rc2/drivers/serial/jsm/jsm_driver.c
linux-2.6.12-rc2-modified/drivers/serial/jsm/jsm_driver.c
62a63
|
67a69
| { PCI_DEVICE (PCI_VENDOR_ID_DIGI,
PCI_DEVICE_NEO_8_DID),0, 0, 4 },
76a79
| { PCI_DEVICE_NEO_8_DID , 8 },
169a173
| case PCI_DEVICE_NEO_8_DID:
diff -r linux-2.6.12-rc2/include/linux/pci_ids.h
linux-2.6.12-rc2-modified/include/linux/pci_ids.h
1532a1533
| #define PCI_DEVICE_NEO_8_DID0x00B1
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCW7oFHI+uMg2HaCcRAraBAJ9ttNr3kTCIM4ztWk6DuMwwmaMVOgCeO8Rl
N7idPCAnZOIevdD4Wguty9w=
=ZFjm
-END PGP SIGNATURE-
-
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] drivers/serial/jsm/: make 2 functions static
Thanks Adrian for helping clean up the driver.
Wendy will integrate your patch into our source tree.
Scott
From: Adrian Bunk [mailto:[EMAIL PROTECTED]
Sent: Sat 4/9/2005 1:04 PM
To: Andrew Morton
Cc: Kilau, Scott; linux-kernel@vger.kernel.org
Subject: [2.6 patch] drivers/serial/jsm/: make 2 functions static
- Forwarded message from Adrian Bunk <[EMAIL PROTECTED]> -
Date: Sat, 2 Apr 2005 01:38:51 +0200
From: Adrian Bunk <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc: linux-kernel@vger.kernel.org
Subject: [2.6 patch drivers/serial/jsm/: make 2 functions static
This patch makes two needlessly global functions static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 2 Apr 2005
drivers/serial/jsm/jsm.h |1 -
drivers/serial/jsm/jsm_neo.c |2 +-
drivers/serial/jsm/jsm_tty.c |4 +++-
3 files changed, 4 insertions(+), 3 deletions(-)
--- linux-2.6.12-rc1-mm4-full/drivers/serial/jsm/jsm_neo.c.old 2005-04-02
00:20:17.0 +0200
+++ linux-2.6.12-rc1-mm4-full/drivers/serial/jsm/jsm_neo.c 2005-04-02
00:20:34.0 +0200
@@ -688,7 +688,7 @@
/*
* No locks are assumed to be held when calling this function.
*/
-void neo_clear_break(struct jsm_channel *ch, int force)
+static void neo_clear_break(struct jsm_channel *ch, int force)
{
u64 lock_flags;
--- linux-2.6.12-rc1-mm4-full/drivers/serial/jsm/jsm.h.old 2005-04-02
00:20:44.0 +0200
+++ linux-2.6.12-rc1-mm4-full/drivers/serial/jsm/jsm.h 2005-04-02
00:20:54.0 +0200
@@ -393,7 +393,6 @@
int jsm_uart_port_init(struct jsm_board *);
int jsm_remove_uart_port(struct jsm_board *);
void jsm_input(struct jsm_channel *ch);
-void jsm_carrier(struct jsm_channel *ch);
void jsm_check_queue_flow_control(struct jsm_channel *ch);
#endif
--- linux-2.6.12-rc1-mm4-full/drivers/serial/jsm/jsm_tty.c.old 2005-04-02
00:21:02.0 +0200
+++ linux-2.6.12-rc1-mm4-full/drivers/serial/jsm/jsm_tty.c 2005-04-02
00:21:18.0 +0200
@@ -31,6 +31,8 @@
#include "jsm.h"
+static void jsm_carrier(struct jsm_channel *ch);
+
static inline int jsm_get_mstat(struct jsm_channel *ch)
{
unsigned char mstat;
@@ -760,7 +762,7 @@
jsm_printk(IOCTL, INFO, &ch->ch_bd->pci_dev, "finish\n");
}
-void jsm_carrier(struct jsm_channel *ch)
+static void jsm_carrier(struct jsm_channel *ch)
{
struct jsm_board *bd;
-
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/5] drivers/serial/jsm: new serial device driver
> Wouldn't you think the kernel already takers are of flow control, given > that it already handles the sending of the X* characters? Hi Russell, Yes. The code was written by me before it was integrated into "serial core". Like your comments suggest, a lot of the "tty" code is now duplicated because of its integration. (And yes, its probably overly complex for just a serial driver, but I was striving for a perfect score in NIST testing...) I believe Wendy plans on continuing to strip out all this duplication of code. Scott - 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
> > DPA support is a requirement for all Digi drivers, so it would > > not be possible for me to remove them from my "dgnc" version > > of the driver. > "requirement" from whom and to who? The Linux kernel community? >From our customers who are moving from other OS's to Linux, and expect DPA support to be under Linux as well. > It's not a reservation issue, it's the fact that we don't want to allow > new ioctls, and if we do, they had better work properly (your > implementation does not.) > > thanks, > > greg k-h Which is fine and I accept the blame for. This is something Wendy can change and fix. I am explaining why they exist today and my argument of why we need them to stay. As it stands today, your requirement appears to be that she needs to yank all diags ioctls and sysfs files before the driver can make it into the kernel sources. This is also fine, but Wendy and IBM will need to decide whether all our diags utilties are needed for the JSM driver or not. Scott - 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
Hi Wendy, Greg, all,
If IBM intends on our DPA management program to work for the JSM
products,
the ioctls are needed.
DPA support is a requirement for all Digi drivers, so it would
not be possible for me to remove them from my "dgnc" version
of the driver.
For the JSM driver, its up to you whether you feel its needed or not.
However, I would like to mention that the DIGI drivers that currently
reside in the kernel sources *do* reserve that ioctl space,
and is acknowledged by "Documentation/ioctl-number.txt":
> d' F0-FF linux/digi1.h
I understand that the list is not a reservation list,
but a current list of potential ioctl conflicts...
But the JSM driver sure doesn't add any new ioctl ranges,
or cause any new conflicts that didn't already exist.
Scott
-Original Message-
From: Wen Xiong [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 09, 2005 11:32 AM
To: Greg KH
Cc: Kilau, Scott; linux-kernel@vger.kernel.org
Subject: Re: [ patch 6/7] drivers/serial/jsm: new serial device driver
Greg KH wrote:
>On Wed, Mar 09, 2005 at 10:50:04AM -0500, Wen Xiong wrote:
>
>
>>+/* Ioctls needed for dpa operation */
>>+#define DIGI_GETDD ('d'<<8) | 248 /* get driver info
*/
>>+#define DIGI_GETBD ('d'<<8) | 249 /* get board info
*/
>>+#define DIGI_GET_NI_INFO ('d'<<8) | 250 /*
nonintelligent state snfo */
>>
>>
>
>Hm, new ioctls still?...
>
>And the structures you are attempting to access through these ioctls
are
>incorrect, so if you are still insisting you need them, at least make
>the code work properly :(
>
>thanks,
>
>greg k-h
>
>
>
Hi Scott,
The above three ioctls are for dpa/managment. If I removed these ioctls,
I have to remove jsm_mgmt.c(patch5.jasmine).
Do you mind I remove jsm_mgmt.c code now? From my side, I don't think I
need them now.
Maybe we can have a solution in the kernel as Russell and Greg said
later.
Thanks,
wendy
-
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 4/7] drivers/serial/jsm: new serial device driver
> > > > If you were to open up the port with an "stty -a" to get the current > > settings and signals, you would unintentionally raise RTS and DTR. > > Why not fix the driver to not change the current line settings if it is > not being opened for the first time? That seems like a much simpler way > to solve this, and probably the saner way, as you don't want any user to > be able to mess up your modem... > > thanks, > > greg k-h Oh, when the port is already open, the driver correctly would not muck with DTR/RTS. I am talking about when the port is currently not open. On first port open, DTR (and usually RTS) will always be raised. The serial device would see this DTR raise, and under some circumstances, react to it... We have customers that use *really* *really* old serial devices on our products, (we are talking 110 baud and even 50 baud (!!!)), where an unintentional raise of DTR/RTS will freak the device out. At any rate, that's the reason I exported the values to sysfs in the original "dgnc" (outside-the-kernel-sources) driver. Thanks, Scott - 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 4/7] drivers/serial/jsm: new serial device driver
> Who needs to know if a port is open or not? > > > +static ssize_t jsm_tty_baud_show(struct class_device *class_dev, char *buf) > No, please delete these, and the other sysfs files that duplicate the > same info that you can get by using the standard Linux termios calls. > There is no need for them here. > > thanks, > greg k-h Hi Greg, Wendy, all, Our serial port monitoring tools need to know these things, and to find them out *without* opening up the serial port to do an ioctl(). For example, lets say a customer has a modem connected to a serial port. If you were to open up the port with an "stty -a" to get the current settings and signals, you would unintentionally raise RTS and DTR. Now the modem sees DTR raised, and might react to it by mistake. Usually raising and dropping RTS/DTR quickly on a modem won't hurt anything, but its not particularly a "good" when the modem is not expecting it. This is why we export the various signals/stats/signals to sysfs (used to be proc), so our management tools can get the information about the serial port without being intrusive by opening up the port. Scott - 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/
