David Campbell (campbell@torque.net)
Sat, 10 Oct 1998 09:56:04 +0800
Date sent:      	Fri, 9 Oct 1998 18:56:33 -0500 (CDT)
From:           	Ely Wilson <plexus@ionet.net>
> Here, I haven't completely looked through this diff i have, because
> basically the diff is teh same size as teh plip.c in 2.0.35 (this diff is
> 2.0.35 against 2.1.124, also this is only a section [need i say that?])
Comparing 2.0.x and 2.1.x kernels is like chalk and cheese.
 
> +plip_init_dev(struct device *dev, struct parport *pb))
>  {
>         struct net_local *nl;
> -       int iosize = (PAR_DATA(dev) == 0x3bc) ? 3 : 8;
> +       struct pardevice *pardev;
> 
> -       /* Check region before the probe */
> -       if (check_region(PAR_DATA(dev), iosize) < 0)
> -               return -ENODEV;
> +       dev->irq = pb->irq;
> +       dev->base_addr = pb->base;
Nothing wrong to this point.
> -       /* Check that there is something at base_addr. */
> -       outb(0, PAR_DATA(dev));
> -       udelay(1000);
> -       if (inb(PAR_DATA(dev)) != 0)
Hmm... This 2.0.x code could be broken on PS/2 style (bidirectional) parallel 
ports. This assumes that bit 5 (0x20) on the printer control register is zero 
(port direction set to write mode), assuming is a very dangerous practice.
> +       if (pb->irq == -1) {
> +               printk(KERN_INFO "plip: %s has no IRQ.\n", pb->name);
>                 return -ENODEV;
That difference is 2.0.x kernels appear to check for the presence of the 
parallel port while 2.1.x kernels will pass a parport structure when a port is 
found. Hence this "if" statement is redundant and should be removed.
> The problem is that the when whoever (sue me) merged parport and plip
> together they felt that checking for a valid irq line was enough to verify
> that the port was useful.
Not to sure who it was, it should be listed in the source code (I hope).
> The old code (-) from 2.0.35 works fine on SPP
> and 'generic Parallel' ports.  e.g. paraports with no assigned irq.
Would be a touch slow without IRQs.
> Unfortunately not every system has the ability to dedicate an
> irq to a lpt port. Such is the laptop here, which is an Austin 486dx2 66
> with a mere 24Mb and a lil old 300Mb HD.
Stop complaining, I have a DX 33 with 8Mb of ram under the desk.
> If anyone more experienced with paraport code or plip code could so kindly
> offer a fix i'd be gracious, until then I'm fiddling with source I know
> little about.
This is more a plip implementation issue and should be handled by the 
maintainer for that driver.
David Campbell
=======================================================
campbell@torque.net
Current project list:
a) Maintain Linux ZIP drivers
b) Create Linux chipset specific parport drivers
c) Start on ParSCSI drivers
Any assistance to clearing this list most welcome
--  To unsubscribe, send mail to: linux-parport-request@torque.net --
--  with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2.0b3 on Wed 30 Dec 1998 - 10:18:33 EST