Re: [patch/rfc 2.6.20-git] parport reports physical devices

From: Randy Dunlap
Date: Mon Feb 19 2007 - 00:33:18 EST

On Sun, 18 Feb 2007 21:08:07 -0800 David Brownell wrote:

> Currently a parport_driver can't get a handle on the device node for the
> underlying parport (PNPACPI, PCI, etc). That prevents correct placement
> of sysfs child nodes, which can affect things like power management.
> This patch resolves that issue for non-legacy configurations:
> * "struct parport" now has a field pointing to that device node,
> and non-legacy port drivers now initialize that device pointer:
> - parport_mfc3 (can't test or build; no Amiga + Zorro here)
> - parport_pc (and stop using only pci_device internally)
> - parport_serial
> - parport_sunbpp (can't test or build, no SPARC + SBUS here)
> * pnp now initializes device dma masks (24bits), preventing oopses
> when generic dma calls are made using pnp device nodes
> * some of the layered parport_driver code now uses that pointer:
> - i2c-parport (parent of i2c_adapter)
> - spi_butterfly (parent of spi_master, allowing cruft removal)
> - lp (creating class_device)
> - ppdev (parent of parportN device)
> - tipar (creating class_device)
> Sanity tested on a PC, where PNPACPI provides the device to parport_pc,
> using spi_butterfly. But I've got to wonder about parport DMA...

Does this patch address ?

What are you wondering about parport DMA?
Please see

*** Remember to use Documentation/SubmitChecklist when testing your code ***
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at