> 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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/