On 1/29/23 8:30?PM, Damien Le Moal wrote: > On 1/24/23 04:09, Ondrej Zary wrote: >> The pata_parport is a libata-based replacement of the old PARIDE >> subsystem - driver for parallel port IDE devices. >> It uses the original paride low-level protocol drivers but does not >> need the high-level drivers (pd, pcd, pf, pt, pg). The IDE devices >> behind parallel port adapters are handled by the ATA layer. >> >> This will allow paride and its high-level drivers to be removed. >> >> Unfortunately, libata drivers cannot sleep so pata_parport claims >> parport before activating the ata host and keeps it claimed (and >> protocol connected) until the ata host is removed. This means that >> no devices can be chained (neither other pata_parport devices nor >> a printer). >> >> paride and pata_parport are mutually exclusive because the compiled >> protocol drivers are incompatible. >> >> Tested with: >> - Imation SuperDisk LS-120 and HP C4381A (EPAT) >> - Freecom Parallel CD (FRPW) >> - Toshiba Mobile CD-RW 2793008 w/Freecom Parallel Cable rev.903 (FRIQ) >> - Backpack CD-RW 222011 and CD-RW 19350 (BPCK6) >> >> The following bugs in low-level protocol drivers were found and will >> be fixed later: >> >> Note: EPP-32 mode is buggy in EPAT - and also in all other protocol >> drivers - they don't handle non-multiple-of-4 block transfers >> correctly. This causes problems with LS-120 drive. >> There is also another bug in EPAT: EPP modes don't work unless a 4-bit >> or 8-bit mode is used first (probably some initialization missing?). >> Once the device is initialized, EPP works until power cycle. >> >> So after device power on, you have to: >> echo "parport0 epat 0" >/sys/bus/pata_parport/new_device >> echo pata_parport.0 >/sys/bus/pata_parport/delete_device >> echo "parport0 epat 4" >/sys/bus/pata_parport/new_device >> (autoprobe will initialize correctly as it tries the slowest modes >> first but you'll get the broken EPP-32 mode) >> >> Note: EPP modes are buggy in FRPW, only modes 0 and 1 work. >> Signed-off-by: Ondrej Zary <linux@xxxxxxx> > > Are you going to send a patch to remove the legacy parport code ? > If we want this queued for 6.3, it is now (this week, asap) or we will > have to delay to 6.4. Unless Jens prefers the deprecation first, which I > think he said "better delete now". I would prefer if we just delete it after merging this one, in the same release. I don't think there's any point in delaying, as we're not removing any functionality. You could just queue that up too when adding this patch. -- Jens Axboe
