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
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
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
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 parpo
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, 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 parport_serial
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 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
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
> >
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
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 disabled
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
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
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
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 framework
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
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 may
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 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 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
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
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 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
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 @@
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 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 body
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
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 be:
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
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
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 info.
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
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.
> See
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
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 a
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.
See messages below.
[...]
[root@localhost /root
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 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
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 the
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
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
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)
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
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
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
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
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
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
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. URL:http://people.redhat.com/twaugh/patches/ The
'extension' is just
On Sat, Apr 07, 2001 at 11:04:38AM +0200, Grard 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
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
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 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 the
On Sat, Apr 07, 2001 at 03:01:57PM +0200, Grard 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 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)
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 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.c
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
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-colon
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
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
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
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
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 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{
/*If
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
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 modules at
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
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 actisys
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
>
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_bool
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
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
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_pc.c
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,
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
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/drivers/p
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
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=none or set by other means dma=none or set by
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/drivers
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/drivers/parport
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 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 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.
Multiple
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 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
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
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
1 - 100 of 265 matches
Mail list logo
