On Tue, Aug 09, 2005 at 12:44:41AM -0400, Dave Jones wrote:
> We have a bunch of 'probe' sysctl's in parport, which are
> readable. (world readable even). Make them write-only.
> Without this, sysctl -a will try to read these files.
??
This change is wrong. The probing happens at module load ti
On Wed, Jul 04, 2001 at 12:58:02PM -0400, John Weber wrote:
> Is there any way to find out up to what ac# level has been merged with
> the current kernel releases (including the pre kernels)?
You can get a diff between two arbitrary patches against the same
thing using interdiff from patchutils
On Wed, Jul 04, 2001 at 01:38:13PM +0100, Alan Cox wrote:
> Can hotplug handle this from a PCI id table ?
There is a PCI id table in parport_serial, yes (if that's what you're
asking).
Tim.
*/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Wed, Jun 27, 2001 at 07:32:42AM -0300, Marcelo Tosatti wrote:
> Could you remove the request_module() from parport_pc ?
Yes.
Here is a patch against 2.4.5-ac24.
Tim.
*/
2001-07-04 Tim Waugh <[EMAIL PROTECTED]>
* drivers/parport/parport_pc.c: Don't load
On Tue, Jun 26, 2001 at 06:59:11PM +0100, Philip Blundell wrote:
> This would be a bit bad, because it would require people to guess
> whether they might have a card that parport_serial can drive and/or
> try loading the module to see what happens.
Not necessarily. The module has a PCI device t
On Tue, Jun 26, 2001 at 10:30:41AM -0300, Marcelo Tosatti wrote:
> > - change parport_pc so that it doesn't request parport_serial at
> > init. In this case, how will parport_serial get loaded at all?
> > Perhaps with some recommended /etc/modules.conf lines (perhaps
> > parport_lowlevel{1
On Tue, Jun 26, 2001 at 03:17:32AM -0300, Marcelo Tosatti wrote:
> If the initialization of parport_serial fails, we obviously get an
> error message, which is really annoying:
[This is different to the issue that is fixed in the -ac tree about
parport_serial getting probed for even when disable
On Thu, Jun 21, 2001 at 03:41:32AM -0700, Balbir Singh wrote:
> I realize that the Linux kernel supports user level drivers (via
> ioperm, etc). However interrupts at user level are not supported,
> does anyone think it would be a good idea to add user level
> interrupt support ? I have a framewo
On Wed, Jun 13, 2001 at 11:39:49PM -0700, Patrick Mochel wrote:
> First off, the patch went into a pre-release of the kernel. Never would I
> trust a pre-release to be stable.
The issue is that of interface stability, as I'm sure you know.
> Second of all, if you look at the big picture, you ma
On Wed, Jun 06, 2001 at 12:24:34PM +0200, Remi Turk wrote:
> Attached is a patch for 2.4.6-pre1 which fixes the help text.
Thanks.
> Also, shouldn't CONFIG_LP_CONSOLE depend on CONFIG_PRINTER=y? (it
> doesn't work when CONFIG_PRINTER=m, at least for me)
It works for me with CONFIG_PRINTER=m.
On Tue, May 29, 2001 at 02:11:56AM +0200, Jamie Lokier wrote:
> Will 4 * inb() cycles have the same effect as 1 * inl() cycle for an EPP
> mode read?
4 inb() cycles on the same port, yes, I think so (but not on
successive ports).
Tim.
*/
PGP signature
On Wed, May 30, 2001 at 01:29:17AM +0200, Erik Mouw wrote:
> I'm still looking for a proper way to automatically include the example
> source into the SGML file, this patch with the same content in two
> files is a bit of an ugly hack.
Probably your best bet is to get the Makefile to pass a copy
On Thu, May 10, 2001 at 05:12:33PM +0200, Jean-Luc Coulon wrote:
> >Huh. Does it do the same thing every time you load parport_probe?
> >Does it always get truncated in the same place?
>
> Yes ! :-/
Nothing really uses that information in 2.2 anyway, so it's harmless
at least. It's probably a
On Wed, May 09, 2001 at 02:43:36PM +0200, Jean-Luc Coulon wrote:
> May 9 13:14:59 debian-f5ibh kernel: parport0: Unspecified, EPSON Styl
Huh. Does it do the same thing every time you load parport_probe?
Does it always get truncated in the same place?
> With 2.4.4-ac6 and 2.4.xx, I get :
> ---
On Fri, Apr 20, 2001 at 05:02:19PM +0100, Alan Cox wrote:
> Thats because I havent sent Linus the docs patches for a few of
> these files yet.
Ah, okay. I wish they didn't error out when that happens..
Tim.
*/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
There's a typo in this file, and also include/asm-i386/io.h has no
extractable documentation.
Tim.
*/
--- linux/Documentation/DocBook/deviceiobook.tmpl.deviceio Fri Apr 20 16:46:16
2001
+++ linux/Documentation/DocBook/deviceiobook.tmpl Fri Apr 20 16:49:23 2001
@@ -171,7 +171,7 @@
On Tue, Apr 17, 2001 at 05:28:13PM -0700, Mr. James W. Laferriere wrote:
> Ok , There isn't a sysctl available to do that . I am also a
> little worried about the 'none' in ths below .
>
> root@udragon:~# sysctl -A | grep -i parp
> dev.parport.parport0.devices.active = none
Don't b
On Tue, Apr 17, 2001 at 05:54:22PM +0200, Udo A. Steinberg wrote:
> To me it's pretty pointless to fill dmesg and the logfiles with
> this rather harmless but still annoying info.
Yes, it's debugging info. I think that FIFO/DMA printing seems to
work quite well now, so maybe it's time to turn t
On Mon, Apr 16, 2001 at 05:54:41PM -0700, Mr. James W. Laferriere wrote:
> # /etc/printcap
> #
> # Please don't edit this file directly unless you know what you are doing!
> # Be warned that the control-panel printtool requires a very strict format!
> # Look at the printcap(5) man page for more i
On Thu, Apr 05, 2001 at 10:52:28PM +0200, Juan wrote:
> Tim Waugh escribió:
> >
> > Could you build a kernel without SMP support and see if the problem
> > still happens?
> Without SMP support, the machine doesn't hang but I can't load the ppa
> module
On Tue, Apr 10, 2001 at 12:55:29PM +0200, kees wrote:
> Unix/Linux have a lot of daemons that have to run as root because they
> need to acces some specific data or run special programs. They are
> vulnerable as we learn.
> Is there any way to have something like an exec call that is
> subject to
On Mon, Apr 09, 2001 at 02:13:10PM +0200, Bjorn Wesen wrote:
> Is it just because nobody has gotten around to "fixing" it or is there a
> deeper reason ?
There's no deeper reason. But there are dependencies involved:
parport needs to be initialised before any parport lowlevel drivers,
and they
On Sun, Apr 08, 2001 at 02:05:36PM +0200, Michael Reinelt wrote:
> The simple solution: Gunters 'multifunction quirks'
> clean solution #1: a new module according to Jeffs sample code
> clean solution #2: 'invisible PCI bridge' from Linus
[...]
> Suggestion: multifunction quirks for 2.4, one of t
On Sat, Apr 07, 2001 at 10:21:11PM +0200, Gunther Mayer wrote:
> Many users will be surprised if they must load another module
> (e.g."pci_multiio") to get their parallel and serial ports working.
>
> Thus _must not_ happen in the stable release.
Yes, I agree. I am planning for parport_serial.
On Sat, Apr 07, 2001 at 03:40:13PM -0400, Jeff Garzik wrote:
> Who said you have to have a separate driver for every single multi-IO
> card? A single driver could support all serial+parallel multi-IO cards,
> for example.
Okay, I misunderstood. I'll take a look at doing this for 2.4.
First of
On Sat, Apr 07, 2001 at 03:23:12PM -0400, Jeff Garzik wrote:
> It's just ugly to keep hacking in special cases to handle hardware
> that is multifunction like this.
I just don't want it to be a huge chore to add support for these
cards.
Would everyone be happy if (say) drivers/parport/parport_s
On Sat, Apr 07, 2001 at 03:01:57PM +0200, Gérard Roudier wrote:
> PCI multi I/O boards _shall_ provide a separate function for each kind of
> IO. Those that donnot are kind of PCI messy IO boards.
But they don't. What are you going to do about it?
> Cheap for whom?
For the guys who make them,
On Sat, Apr 07, 2001 at 01:23:27PM -0400, Jeff Garzik wrote:
> You asked in your last message to show you code, here is a short
> example. Note that I would love to rip out the SUPERIO code in parport
> and make it a separate driver like this short, contrived example. Much
> more modular than t
On Sat, Apr 07, 2001 at 02:53:23PM -0400, Jeff Garzik wrote:
> As has been explained, the current API supports this just fine without
> modification.
The current API makes it much harder to support the breadth of
hardware we're talking about.
The hardware has quirks, and this quirk is so common
On Sat, Apr 07, 2001 at 08:42:35PM +0200, Gunther Mayer wrote:
> Please apply this little patch instead of wasting time by
> finger-pointing and arguing.
This patch would make me happy.
It would allow support for new multi-IO cards to generally be the
addition of about two lines to two files (w
On Sat, Apr 07, 2001 at 11:04:38AM +0200, Gérard Roudier wrote:
> Given your description, this board is certainly not a multi-fonction PCI
> device. Multi-function PCI devices provide separate resources for each
> function in a way that allows each function to be driven by separate
> software dri
On Sat, Apr 07, 2001 at 01:33:25PM +0200, Michael Reinelt wrote:
> Adding PCI entries to both serial.c and parport_pc.c was that easy
And that's how it should be, IMHO. There needs to be provision for
more than one driver to be able to talk to any given PCI device.
Tim.
*/
PGP signature
On Sat, Apr 07, 2001 at 04:57:29AM -0400, Jeff Garzik wrote:
> Where is this patch available? I haven't heard of an extension to the
> pci id tables, so I wonder if it's really in the queue for the official
> kernel.
It is. http://people.redhat.com/twaugh/patches/> The
'extension' is just 'mo
On Thu, Apr 05, 2001 at 09:06:20AM -0400, Bart Trojanowski wrote:
> So you ask: "why not just use a { ... } to define a macro". I don't
> remember the case for this but I know it's there. It has to do with a
> complicated if/else structure where a simple {} breaks.
It's for eating the semi-col
On Wed, Apr 04, 2001 at 12:59:33AM +0200, Juan wrote:
> I have the same problem in two different machines but they both are UP.
> However, my kernel configuration has SMP support enabled.
Could you build a kernel without SMP support and see if the problem
still happens?
> options parport_pc io=
On Tue, Apr 03, 2001 at 02:08:13AM +0200, Stefan Linnemann wrote:
> the necessary features. I copied .config from the 2.2.17, superficially
> checked the config, and remade and rebooted.
>
> This was where I noted, that the parport, paride, epat and pd modules didn't
> get installed as module
On Sat, Mar 31, 2001 at 01:59:39AM +0200, Juan Piernas Canovas wrote:
> Yes!!!. It works. I am happy now :-)
Unfortunately, the problem isn't solved, merely worked around. We
need to figure out why this is happening in the first place.
To recap, the system hangs completely when you load the pp
On Tue, Apr 03, 2001 at 01:53:26AM -0700, Allen Ashley wrote:
> ---
> soval=fcntl(s,F_GETFL,0);
> ioval=fcntl(0,F_GETFL,0);
> fcntl(s,F_SETFL,soval|O_NONBLOCK);
> fcntl(0,F_SETFL,ioval|O_NONBLOCK);
> cwait=WAITCONNECT;
> *chin=0;
> do{
>
On Mon, Apr 02, 2001 at 10:40:00AM +, Destroy micro$oft wrote:
> The first time I booted 2.4.3, the system came
> up to the login prompt and promptly froze.
> The second time, I tried to start X, and it
> froze again. Never seen this with the older
> kernels.
Version of X?
> I've got my act
On Sat, Mar 31, 2001 at 04:00:27PM +0200, Pozsar Balazs wrote:
> On Fri, Mar 30, 2001 at 10:17:08PM +0200, Herbert Rosmanith wrote:
> In fact, if we want to get what is said in the comment, we should write:
>
> if [ "$CONFIG_PARPORT" = "m" -a "$CONFIG_PARIDE_PARPORT" = "y" ] ; then
>define_b
On Fri, Mar 30, 2001 at 10:17:08PM +0200, Herbert Rosmanith wrote:
> why not simply write:
>
> define_bool CONFIG_PARIDE_PARPORT $CONFIG_PARPORT
>
> instead?
Because it isn't that simple. PARIDE works with parport, or without
parport, but if parport is a module then PARIDE must be confi
On Fri, Mar 30, 2001 at 03:55:01PM +0200, Juan Piernas Canovas wrote:
> The kernel configuration is the same in both 2.2.17 and 2.2.19.
> Perhaps, the problem is not in the ppa module, but in the parport,
> parport_pc or parport_probe modules.
There weren't any parport changes in 2.2.18->2.2.19,
Currently the VIA SuperIO chip's parallel port support uses IRQs
regardless of whether the user says not to. This patch addresses
that. Please let me know if there are problems with it.
Thanks,
Tim.
*/
2001-03-30 Tim Waugh <[EMAIL PROTECTED]>
* drivers/parport/parport
Oops, the last patch isn't the one I meant to send. Here is the right
one.
Tim.
*/
2001-03-27 Tim Waugh <[EMAIL PROTECTED]>
* parport_pc: Fix save/restore_state to take account of the soft
control port.
* ChangeLog: Updated.
--- linux/driv
This fixes a printing bug that only seems to show up with some
chipsets. Please apply.
Thanks,
Tim.
*/
2001-03-27 Tim Waugh <[EMAIL PROTECTED]>
* parport_pc: Fix save/restore_state to take account of the soft
control port.
* ChangeLog: Updated.
--- linux/d
On Wed, Mar 21, 2001 at 07:41:15PM -0700, TimO wrote:
> 0x378: possible IRQ conflict! [Don't know why it always reports
> this]
I've been sending Linus a patch to remove this bogus warning for the
last few pre-patches.
> 0x378: ECP settings irq= dma= other means>
[...]
> With no options i
On Sun, Mar 25, 2001 at 09:37:38PM -0800, [EMAIL PROTECTED] wrote:
> do_pd_read_drq: status = 0x10050 = SEEK READY TMO
Please try a recent -ac kernel and let me know if the problem persists
or goes away.
Tim.
*/
PGP signature
On Sat, Mar 24, 2001 at 01:55:15AM +0100, J . A . Magallon wrote:
>
> On 03.24 Andrew Morton wrote:
> > "J . A . Magallon" wrote:
> > >
> > > The same is with that ugly out: at the end
> > > of the function. Just change all that 'goto out' for a return.
> >
> > Oh no, no, no. Please, no.
> >
On Fri, Mar 23, 2001 at 01:38:00AM +0100, J . A . Magallon wrote:
> Yes, a null sentence can shut up the compiler. But what is the purpose of
> a jump to the end instead of a return ? Some optimization ?
So that when someone decides that the function needs to do some extra
initialisation at the
On Wed, Mar 21, 2001 at 09:19:35AM -0500, Jeff Garzik wrote:
> Attempting to pretend that the parallel port is not in an interrupt
> driven mode by passing irq=none is folly.
No, that's not what it's for. It means 'for Christ sake don't use
interrupts, I know what I'm doing'.
> If irq=none is
On Tue, Mar 20, 2001 at 11:21:10PM -0500, Jeff Garzik wrote:
> The current Via-specific parport_pc.c code forces on the best possible
> parallel port modes the chip can handle. In retrospect, what it should
> be doing is reading the configuration BIOS has set up, and not touching
> it.
Yes, I t
It's easier to add parallel ports to a machine nowadays, so the
default maximum of three printer devices is becoming a bit
restrictive.
Here's a patch to increase it. Any objections?
Tim.
*/
2001-03-19 Tim Waugh <[EMAIL PROTECTED]>
* include/linux/parport.h: Increas
On Mon, Mar 19, 2001 at 12:16:26AM +, Will Newton wrote:
> In /etc/modules.conf I have:
>
> options parport_pc irq=none
>
> but dmesg says:
>
> parport0: PC-style at 0x378 (0x778), irq 7, dma 3
> [PCSPP,TRISTATE,COMPAT,ECP,DMA]
Jeff, this is a bug with the Via code in parport_pc.c. Basic
On Sat, Mar 17, 2001 at 01:05:51AM -0500, Michael B. Allen wrote:
> I setup everything as you describe below. I don't remember having to
> do all this stuff before(on other machines anyway). I guess I'm used to
> RH's fluffed-up stock kernels.
Which stock kernel didn't work for you?
Tim.
*/
-
T
On Fri, Mar 16, 2001 at 06:52:53PM -0500, Michael B. Allen wrote:
> The parallel port is not being detected on my ABIT KT7A KT133 w/ Athlon
Need dmesg output to see what parport is being told and what is
finding out for itself.
> BIOS options are:
>
> 728/IRQ5
^^^ 278, probably
> 378/IRQ7
>
On Thu, Mar 15, 2001 at 06:45:37PM +, Will Newton wrote:
> I don't know why it prints it twice.
Looks like the module is getting loaded, then unloaded, then loaded
again. Perhaps because of module autocleaning?
> When printing errors are printed (buffer overrun or something like that,
> it
On Wed, Mar 07, 2001 at 01:50:35PM +0100, f5ibh wrote:
> Mar 7 11:55:55 debian-f5ibh lpd[567]: lp: filter 'f' terminated (termsig=13)
Which filter?
Does the patch I posted yesterday help?
Tim.
*/
PGP signature
This patch should make printer status readback a little less broken
than before.
2001-06-03 Tim Waugh <[EMAIL PROTECTED]>
* drivers/char/lp.c (lp_read): The loop is broken. Remove it,
and restore 2.2.x behaviour.
--- linux/drivers/char/lp.c.readbackTue Mar 6 16
Some of the fixes to the PCI documentation got lost in the 2.4.3-pre1
patch. Here they are again.
Tim.
*/
2001-03-02 Tim Waugh <[EMAIL PROTECTED]>
* drivers/pci/pci.c: Inline documentation, based on a patch by
Jani Monoses.
--- linux/drivers/pci/pci.c.pcidoc Sat
Linus,
Here is a patch that makes 2.4.x's behaviour more closely match that
of 2.2.x when a nibble mode read goes wrong. It prevents reading
processes from getting stuck in certain circumstances.
Tim.
*/
2001-03-02 Tim Waugh <[EMAIL PROTECTED]>
* drivers/parport/iee
On Tue, Feb 27, 2001 at 10:40:35PM +, Andrew Morton wrote:
> 1: Your code is leaving the semaphore in a down'ed state
>somehow.
This was probably it. I don't know why it works for me but not some
other people though. :-/
> (As you can tell, I'm desparately avoiding having
> to understa
Hi Linus,
This patch seems to cure some printing stalls that some people have
been seeing. The down_trylock call isn't really needed there anyway.
Please apply.
Tim.
*/
2001-02-27 Tim Waugh <[EMAIL PROTECTED]>
* drivers/parport/ieee1284_ops.c: Remove down_t
On Tue, Feb 27, 2001 at 12:59:48PM -0700, Don Dugger wrote:
> Isn't `perl' overkill? Why not just:
>
> tr -d '\r'
while read line; do echo ${line%?}; done
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordom
On Sun, Feb 25, 2001 at 11:10:39PM +, Andrew Morton wrote:
> I think there might be a bogon in __down_interruptible's
> handling of the semaphore state in this case. I remember
> spotting something a few months back but I can't immediately
> remember what it was :(
>
> I'd suggest you slot
I'm trying to chase down a semaphore time-out problem. I want to
sleep on a semaphore until either
(a) it's signalled, or
(b) some amount of time has elapsed.
What I'm doing is calling add_timer, and then down_interruptible, and
finally del_timer. The timer's function ups the semaphore.
The c
On Fri, Feb 23, 2001 at 08:46:23AM +0100, Giacomo Catenazzi wrote:
> After writing the report, I disabled parport resources in BIOS
> and I maked:
>
> cate3:~# modprobe parport_pc
> Unable to handle kernel paging request at virtual address
> c3a5f640
> printing eip:
> .
> Segmentation fault
On Thu, Feb 15, 2001 at 11:52:46AM +0100, Igmar Palsenberg wrote:
> Attached is a patch to make a Netmos PCI parallal port card working.
Please try the following patch instead. That card _should_ have a
working ECR.
ftp://people.redhat.com/twaugh/patches/linux24/linux-netmos.patch>
Tim.
*/
On Wed, Feb 14, 2001 at 08:15:55AM -0500, Allen Barnett wrote:
> Is this a bug or is there a new (or better) procedure for reading data
> through the lp device in 2.4?
Bug, I think.
Tim.
*/
PGP signature
On Wed, Feb 14, 2001 at 05:14:19AM -0600, Jeff Garzik wrote:
> Should the call to pci_unregister_driver in cleanup_module be
> conditional on registered_parport as well? I didn't check...
No. (cleanup_module is only called if init_module succeeded.)
> Also, is it possible to convert parport_pc
On Wed, Feb 14, 2001 at 10:21:38PM +1100, Andrew Morton wrote:
> Now, if there were some actual COMMENTS (scary, I know) in the pci
> code which described the API, stuff like this wouldn't happen.
Oh yeah, that reminds me: if someone would like to make sure that the
following changes are accurat
On Wed, Feb 14, 2001 at 02:03:07AM -0600, Jeff Garzik wrote:
> If pci_register_driver returns < 0, the driver is not registered with
> the system.
Thanks. Okay, second try:
2001-01-14 Tim Waugh <[EMAIL PROTECTED]>
* parport_pc.c: Fix PCI driver lis
Linus,
Here's a patch that fixes a bug that can cause PCI driver list
corruption. If parport_pc's init_module fails after it calls
pci_register_driver, cleanup_module isn't called and so it's still
registered when it gets unloaded.
Tim.
*/
2001-01-13 Tim Waug
On Mon, Feb 12, 2001 at 10:50:23PM +0100, John B. Jacobsen wrote:
> Starting lpd: Warning - lp: cannot open lp device '/dev/lp0' - No such device
> Warning - dj: cannot open lp device '/dev/lp0' - No such device
>
> Why is that ? /dev/lp surely exists !
It's telling you that the driver is not l
On Wed, Jan 17, 2001 at 09:32:30PM +0100, Sven Koch wrote:
> reverse the patch for 2.4.1pre7
>
> for example: cd /usr/src/linux ; zcat 2.4.1pre7.gz | patch -p1 -R
>
> after that apply pre8
You can also use interdiff:
$ interdiff 2.4.1pre7 2.4.1pre8 | patch -p1
It's mostly reliable.
Tim.
*/
Looks like you didn't configure your kernel with printer support. You
want CONFIG_PRINTER.
Tim.
*/
PGP signature
On Thu, Jan 11, 2001 at 06:29:27PM +0100, f5ibh wrote:
> I got this non-fatal oops while loading the ppa module for my IOMEGA parallel
> port ZIP drive.
It doesn't look like it's related to the ZIP drive though:
> Warning: kfree_skb passed an skb still on a list (from c8074fc1).
> Oops: 0002
>
On Tue, Jan 09, 2001 at 03:53:02PM -0500, Douglas Gilbert wrote:
> by timeouts ** resulting in scsi bus resets. Anyway the problem
> seems to disappear with the recently released SANE 1.0.4 .
> [The original report was based on SANE 1.0.3 and earlier.]
In fact my report that the problem went awa
I'm having problems with using xsane to acquire a preview from an HP
ScanJet 5P connected to an AHA-2940. 2.3.42 is the last kernel that
works right for me.
The symptom is that the scanner starts to make scanning sounds, then
stops, and xsane says 'Error during read: Error during device I/O'.
A
Linus, here is a patch from Adam J. Richter to add the tiny kernel
hook for device-id based parport device driver module loading, as well
as an example usage in lp.c. (The code for making use of it is already
in modutils.)
Tim.
*/
2001-01-05 Adam J. Richter <[EMAIL PROTECTED]>
* inclu
Here is a patch that changes the superuser check in lp to use
capabilities instead.
Does anyone see a problem with it before I send it to Linus?
Tim.
*/
2001-01-05 Tim Waugh <[EMAIL PROTECTED]>
* drivers/char/lp.c: Capability check instead of superuser check.
Patc
des. Here's a patch to do that. Look okay?
Tim.
*/
2001-01-04 Tim Waugh <[EMAIL PROTECTED]>
* drivers/char/lp.c: Follow 2.2 behaviour more closely.
--- linux-2.4.0-prerelease/drivers/char/lp.c.offlineThu Jan 4 21:13:02 2001
+++ linux-2.4.0-prerelease/drivers/cha
On Thu, Jan 04, 2001 at 11:20:51PM +0100, Gunther Mayer wrote:
> this mapping must be hardcoded like I did for Timedia serial:
I was thinking about using another flag, like SPCI_FL_SEE_BELOW_TOO,
to mean 'look at the next entry too'. Then I could just have both
entries there one after the other
On Thu, Jan 04, 2001 at 03:39:10PM +0100, Andrea Arcangeli wrote:
> As noted yesterday falling into parport_write will silenty lose data when the
> printer is off.
(Actually it depends; I think FIFO/DMA paths are fine, but yes, the
software implementation can lose data.)
> If it's not feasible
On Thu, Jan 04, 2001 at 02:52:29PM +0100, Andrea Arcangeli wrote:
> I think lp_check_status.
Okay. So what about this patch instead? If the printer is off-line
to start with, fall into parport_write anyway (it will just time out
and return 0). If LP_ABORT is set, we return -EAGAIN.
Tim.
*/
On Wed, Jan 03, 2001 at 07:44:19PM +0100, Peter Osterlund wrote:
> When trying to print to an off-line printer with 2.4 kernels, the
> "write" system call to /dev/lp0 stalls for 10 seconds and then returns
> EIO.
I wonder where the EIO is coming from though. Grep only shows up
ieee1284.c (in pa
On Thu, Jan 04, 2001 at 02:39:21AM +0100, Andrea Arcangeli wrote:
> On Thu, Jan 04, 2001 at 02:09:56AM +0100, Peter Osterlund wrote:
> > should say that it is obsolete. I think obsolete means "you should never
> > ever have to use this stuff".
>
> Agreed.
I think that LP_CAREFUL is still needed
On Thu, Jan 04, 2001 at 01:08:01AM +0100, Peter Osterlund wrote:
> The tunelp man-page seems to think there are printers that need the
> LP_CAREFUL handling. I also noted that if I disconnect my printer from
> the computer, the data will no longer be lost. Apparently the printer
> confuses the pa
On Tue, Jan 02, 2001 at 11:22:55PM +0100, Stefan Frank wrote:
> 2 days ago i upgraded to 2.4.0-prelease, today suddenly i had the same
> symptom. I've been running 2.4.0-test10 since it's been released and never
> saw this happen there.
I get this on 2.2.18 too, and it never used to happen with
I've got a PCI serial card here that I'm not sure how to add support
for. It's resource map is like this:
Product name | Ven.ID | Dev.ID |[Base+10]|[Base+14]|[Base+18]|[Base+20]|
---+++-+-+-+-+
VScom PCI-400L | 14D2 | 8040 |
Does anyone have an OXSEMI PCI parallel port PCI card with device id
0x9513 (i.e. an OXSEMI 16PCI954)?
I'd like to get them to try out something..
Thanks,
Tim.
*/
PGP signature
On Mon, Dec 18, 2000 at 07:40:03PM +, Alan Cox wrote:
> o Add documentation to the PCI api(Jani Monoses)
Needs this:
--- linux-2.4.0test13pre3-ac1/drivers/pci/pci.c.pcidoc Mon Dec 18 20:46:08 2000
+++ linux-2.4.0test13pre3-ac1/drivers/pci/pci.c Mon Dec 18 20:51:20 2000
On Mon, Dec 18, 2000 at 07:40:03PM +, Alan Cox wrote:
> o Teach kernel-doc about const(Jani Monoses)
Needs this (also cleans up kernel-doc macro handling and fixes some
regexps):
--- linux-2.4.0test13pre3-ac1/scripts/kernel-docMon Dec 18 20:46:11 2000
+++ lin
On Mon, Dec 18, 2000 at 07:40:03PM +, Alan Cox wrote:
> o Mark the parport fifo code as experimental (Tim Waugh)
Needs this:
--- linux-2.4.0test13pre3-ac1/drivers/parport/Config.in Mon Dec 18 20:45:54 2000
+++ linux-2.4.0-test13-pre3+/drivers/parport/Config.in Mon Dec 18 16:56
On Mon, Dec 18, 2000 at 10:17:17PM +0200, Jani Monoses wrote:
> Tim Waugh pointed out this wasn't good as 'const' is part of the function
> signature and he now has a better patch.
I'll sync up with Alan.
Tim.
*/
-
To unsubscribe from this list: send the line "u
On Sun, Dec 17, 2000 at 05:22:23PM +0100, Andrzej Krzysztofowicz wrote:
> Why it does not depend on CONFIG_EXPERIMENTAL if it really is experimental ?
Oh, missed that. Thanks, fixed.
Tim.
*/
PGP signature
On Sat, Dec 16, 2000 at 05:26:09PM +0200, Jani Monoses wrote:
> kernel-api.tmpl references the exported functions of kmod.c but
> there are none.
There are: hotplug_path, exec_usermodehelper, call_usermodehelper,
request_module.
Try adding kmod.c to APISOURCES in the Makefile.
Tim.
*/
-
On Sat, Dec 16, 2000 at 05:37:51PM +0200, Jani Monoses wrote:
> + * Otherwise if @from is not %NULL, searches continue from that point.
Searches continue from the next one I think.
> + * pci_register_driver - register a new pci driver
[...]
> + * pci_unregister_driver - unregister a pci driver
Hi Linus,
Here is a patch to make the parport_pc comments better. No code
change.
Tim.
*/
2000-12-17 Tim Waugh <[EMAIL PROTECTED]>
* drivers/parport/parport_pc.c: Better commentary. Patch from
R Horn.
* drivers/parport/ChangeLog: Updated.
--- linux-2.4.0-
Hi Linus,
This patch adds inline documentation to a couple of macros, with
improvements suggested by Andi Kleen.
Tim.
*/
2000-12-13 Tim Waugh <[EMAIL PROTECTED]>
* include/linux/init.h, include/linux/module.h: Inline
documentation for some macros. Patch from Armin
Hi Linus,
This patch fixes some timing issues with ppa.
Tim.
*/
2000-12-13 Tim Waugh <[EMAIL PROTECTED]>
* drivers/scsi/ppa.c, drivers/scsi/ppa.h: Timing fixes. New
parameter "recon_tmo=". This is 2.07-for-2.4.x.
--- linux-2.4.0-test12/drivers/scsi/ppa.c.p
1 - 100 of 141 matches
Mail list logo
