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 http://bugzilla.kernel.org/show_bug.cgi?id=5496 ? What are you wondering about parport DMA? Please see http://bugzilla.kernel.org/show_bug.cgi?id=7491 and http://bugzilla.kernel.org/show_bug.cgi?id=7492 --- ~Randy *** 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
