>
> 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]>
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
> > > > > 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
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
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, wit
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 w
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
wor
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
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.
>
27;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: Chr
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 le
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
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
> 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 wan
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 chang
?
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
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
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
> 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
> > 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 su
sday, 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 dp
> >
> > 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
wa
> 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
23 matches
Mail list logo
